Success in a Founding Engineer role at Seed Stage

I'm the first and only engineer at a YC seed startup. When I took the job, I thought success meant writing good code, building clean systems, making smart architectural decisions. A year in, I've learned that almost none of that is what the job is actually about.

Your job isn't engineering. It's buying time

At seed stage, the company is still proving it deserves to exist. Every week you're either moving closer to the next milestone or you're burning runway without enough to show for it. That changes what success looks like as an engineer.

Success isn't a well-architected system. It's the feature that stops a customer from churning. It's the integration you hacked together in a day because a prospect said they'd sign if you had it. It's the ugly fix that keeps things running over the weekend so the founders can close a deal on Monday.

I've shipped things I'm not proud of technically that directly contributed to keeping a customer. I've also spent time making something "right" only to realize that customer didn't care about that feature at all.

The mental model that helped me was thinking of every hour I spend as either buying the company more time or not. More time means more runway, more customers, more room to eventually do things properly.

Before we were about to close our first enterprise customer, I had to rework our whole auth and workspace handling logic. In a week, without breaking existing customer flows. And it was a mess when I took it up. We were exclusively using the Supabase ORM, both in frontend and backend, to make DB calls. This worked because we did not have any workspace logic and every user had their own data. I had to change everything so that certain users could be in a shared view. This meant cleaning the entire frontend of Supabase calls and doing it from the server side because if data is shared, you can't rely on Supabase RLS to handle access control. You have to do it on your own. And with data making the hop over a server, API response times were getting abysmal. So I had to write raw SQL queries, albeit with Claude Code, to do the more complex fetches for frontend dashboards. Realistically, this change done right would take 3-4 weeks. I had to do it in 1. Because the customer was going to be onboarded in a week. I did it. It was messy, some niche things were still broken, but it led to a six figure multi-year enterprise deal.

That week taught me more about what this job actually is than my first three months combined.

The loneliness is real and nobody warns you

There is no one else who understands the codebase. Not in the way I do. The CTO reviews PRs and has opinions on architecture, but he's not in the code eight hours a day. When something breaks, it's me. When I'm stuck on a hard problem at 1 AM IST, there's no senior engineer to message. There's no one to pair with, no one to rubber duck with, no Slack channel of engineers debating whether this should be a queue or a cron job.

I didn't expect this to be the hardest part of the role. I thought the hard part would be the technical challenges or the pace. The pace is fine. The loneliness is the thing that actually gets to you.

It shows up in small ways. You make a technical decision and there's no one to validate it. You refactor something significant and there's no one who appreciates what changed or why it was necessary. You have a breakthrough on a tricky bug and there's no one who understands why that's exciting. The founders care about the outcome, not the how. That's their job. But it means the engineering wins are yours alone, and so are the engineering mistakes.

There was a week, maybe two months in, where I was migrating one of our long running data pipelines with a pause-resume feature. The old system had pipelines that ran for hours and once started, the configurations of those runs couldn't be changed. It was a nightmare and I was the only person who knew it was happening. I spent three days adding it to all long running data pipelines, barely talking to anyone because there was nothing to talk about until it worked. When I finally shipped it, the message in Slack was something like "long data pipelines can now be paused & resumed to change configs" My CTO said "nice." That was it. The feature worked. Customers didn't notice because that was the whole point. And I sat there thinking, I just mass overhauled our most critical system and the correct response from everyone else was basically no response. That's the loneliness. Not dramatic. Not a crisis. Just a quiet absence of anyone who gets what you just did.

I haven't fully solved this. I have a few ex colleagues who are in the same founding engineer roles in startups and those conversations help. But I'd be lying if I said the loneliness doesn't still hit on a random Tuesday at midnight when I'm debugging something alone and wondering if the approach I'm taking is even right.

Agency is the moat

There are a lot of engineers who are more technically skilled than me. Better at system design, better at algorithms, more years of experience. What most of them can't do is operate without a spec.

At a seed startup, nobody hands you a detailed ticket with acceptance criteria and a figma link and says go build this. Most of the time, the problem itself isn't fully defined. A customer complains about something vague. A founder mentions an idea in passing on a call. A metric is trending in the wrong direction and nobody knows why. The founding engineer is the person who sees that, decides it matters, figures out what the solution should be, builds it, and ships it - without being asked, without waiting for permission, without needing someone to break it down into manageable chunks.

That's agency. And it's the single biggest thing that separates people who thrive in this role from people who struggle with it.

I've seen it in myself. My best weeks aren't the ones where I execute a well-defined list of tasks efficiently. They're the ones where I noticed something - a pattern in support tickets, a drop in a dashboard, a friction point I experienced while dogfooding - and just went and fixed it. No ticket. No standup discussion. No "let me check with the team." Just saw it, scoped it, shipped it.

A few weeks back while checking our Salesforce integration logs for something else, I found that for a particular customer, some records were not syncing to their CRM. This was because the access tokens we had did not have the permission to write to their Salesforce. I made a change so that syncs are not blocked because of this, raised a PR, and asked to CEO to ask the customers to unblock access to the key. Wrote a notion doc on why this happened, and all of it was resolved in 2 hours.

The reason this is a moat is that it's not a skill you can learn from a tutorial. It comes from caring enough about the product to pay attention, being close enough to the customer to understand what matters, and having the confidence to act on your own judgment. A second engineer can be onboarded onto the codebase. They can't be onboarded onto the instinct of knowing what to build next.

The only engineering skill that matters is scoping

This might be the most counterintuitive thing I've learned. Coming into this role, I cared a lot about writing clean, well-structured, readable code. Good variable names. Proper abstractions. DRY principles. The stuff you're taught makes you a good engineer.

Almost none of it matters the way I thought it did.

At seed stage, code is disposable. Features get rewritten. Entire modules get thrown away when the product direction shifts. The API you spent a week making elegant gets deprecated a month later because the customer needed something different. And now with AI tools writing most of the implementation, the code itself is even more disposable - if Claude wrote it, Claude can rewrite it.

What does matter is the decisions above the code. Which feature to build. How to scope it so it ships in two days instead of two weeks. What data model to use so you're not locked into a corner. Where to put the boundary between "good enough" and "needs to be solid." Those decisions are the real engineering at this stage. The code is just the output.

This doesn't mean write garbage on purpose. It means stop optimizing for code quality as your measure of success. The engineer who ships a messy feature that retains a customer is more valuable than the engineer who ships a beautiful feature that nobody asked for.

The biggest part of that judgment is knowing what deserves your time. Knowing when to be careful vs when to ship quick is the instinct that defines whether you're good at this role or not. And no one can teach it to you - you just develop it by getting it wrong enough times.

Some things you ship in two hours with duct tape everywhere. The customer needs it by tomorrow. The data model isn't perfect but it works. You'll clean it up later. Sometimes you do clean it up later. Most times you don't, and that's fine because most times it never mattered.

Some things you slow down for. The payments integration. The data pipeline that every other feature depends on. Get these wrong and you're not just creating technical debt - you're creating a mess that actively blocks future work. The cost of rebuilding a foundation is ten times the cost of building it carefully the first time.

My heuristic, roughly: if a mistake here means a customer sees broken data or we lose money, slow down. If a mistake here means something looks slightly off or a workflow is a little clunky, ship it and fix it when someone complains. No one has ever complained about most of the things I thought they'd complain about.

The other thing no one tells you is that this heuristic changes as the company grows. At 100K ARR, almost everything should be fast. At 500K, there are now customers and revenue streams that depend on things not breaking. The bar for "slow down" gets lower over time. The things you duct-taped at 100K start becoming the things that break at 500K.

What I'd tell someone starting this role

You are not being hired to write code. You are being hired to make sure the company is still alive in six months. Everything else - the architecture, the code quality, the tech stack decisions - is in service of that. The moment you internalize this, every decision gets easier.

Your instincts will be wrong a lot in the first few months. You'll over-engineer things that don't matter and under-engineer things that do. That's not failure. That's calibration. The only real failure is not shipping.

And the thing nobody says out loud - this role will be the loneliest job you've ever had and simultaneously the most formative. You will learn more in one year as a founding engineer than most people learn in five years at a bigger company. Not because you're smarter. Because there's nobody else to do it. That constraint is the gift, even when it doesn't feel like one.