Why I keep choosing startups

I've been asked, in interviews and by relatives, why I don't just take a comfortable job. I'm still in university. I have a résumé that would get me in the door at a big company. Why keep doing the hard, uncertain version?

The honest answer is that I've done the other thing, briefly, and I learned less in a quarter there than I learn in a week at a startup. That's not a complaint about big companies. It's a statement about feedback loops.

The feedback loop is the whole thing

At a startup, the distance between "I wrote this" and "a real person used this and it either worked or it didn't" is measured in hours. Sometimes minutes. At Tsenta I can ship a change to an ATS integration and watch the success rate for that platform move on a dashboard before I've finished my coffee.

That loop is how you actually learn. Not courses. Not code review from someone who has never run the thing in production. Watching your decision hit reality and being the person who has to fix it when reality disagrees.

At scale, that loop stretches to weeks. The thing you built goes through three reviews and a release train and a staged rollout, and by the time it's in front of users you've moved on and someone else owns the bug. You get promoted for shipping. You don't get taught by shipping.

Three companies, three different lessons

Pronexus Tech — I founded it in 2022, a small studio building web and mobile products for clients. What it taught me: how to finish. Client work has a delivery date and an invoice attached, and nobody cares how elegant the architecture is if it's late. Ten-plus shipped products, a team I had to actually manage, and the first time I understood that "done" is a skill separate from "good."

Percify — I joined as CTO in 2025 and took an AI avatar platform from an empty repo to an acquisition in ten months. What it taught me: ownership across the whole stack is a different job from being good at any one part of it. I designed the monorepo, the billing, the AI generation pipeline, the analytics over 100M+ daily events, the deploy system. I was decent at all of it. I was excellent at none of it. And when the company was acquired, the thing the acquirer valued wasn't any single component — it was that the whole system held together under real load with a very small team.

Tsenta — YC S26, founding engineer, March 2026 to now. What it's teaching me: depth. I own one thing here, the backend and the ATS integrations, and it runs 200,000+ applications a day. I went from a bigger title to a smaller one on purpose, because I wanted to find out how good I could get at one hard problem instead of being adequate at fifteen.

What "startup" actually means to me

It doesn't mean chaos, and it doesn't mean 80-hour weeks as a personality. The good ones are calmer than people think, because there's no room for politics — the only question in any meeting is "does this make the product better for the person using it."

It means:

• You own outcomes, not tasks. Nobody hands you a ticket. You notice the failure rate on Lever spiked, and you fix it, and you write the postmortem, and you decide whether it's worth building a canary for.
• Cost is a design constraint. We cut infrastructure spend 40% without touching reliability, and that wasn't an optimisation sprint — it was the result of asking, for every feature, "what does this cost per request and is that worth it." At a big company that's someone else's spreadsheet.
• Your name is on it. When a user on r/Tsenta posts that the autofill missed a field, that's not a support ticket routed to a queue. That's me, that evening, reading the trace.

The honest downside

It's uncertain. Percify could have not been acquired. Tsenta could not work out. Every startup I've joined has been a bet with real odds of zero, and I've made those bets while carrying a full course load at Presidency University with a degree that finishes in 2027.

I'm okay with that, because the thing I'm accumulating isn't the equity. It's the reps. Three companies of real production systems, real users, real failures, real fixes — by the time I graduate, I'll have shipped more into production than most engineers do in their first five years. That compounds regardless of how any single bet lands.

If you're deciding

Go where the loop is shortest. Go where you'll be the person who has to fix it at 2am, because that's the person who learns what actually breaks. Titles are a bad proxy for what you're learning. Pick the problem.