From 0 to 1: How I Approach Founding-Engineer Work

Founding-engineer work looks like coding. It's actually a sequence of bets about what to build, what to skip, and what to throw away later. The code is the easy part.

After doing this across several startups, here's the mental model I keep coming back to.

Optimize for reversibility, not correctness#

Early on, you don't have enough information to be correct. So don't aim for correct — aim for reversible. Choices you can undo cheaply are choices you can make quickly.

Reversible: a schema you can migrate, a service you can rewrite.
Irreversible: your data model's core assumptions, your auth boundaries, your public API shape.

Spend your deliberation budget on the irreversible decisions. Move fast on everything else.

Ship the spine first#

I build the thinnest end-to-end slice that proves the product works, then widen it. A working spine beats a beautiful limb.

Week 1:  auth → create → view (ugly, but real)
Week 2:  make it not embarrassing
Week 3:  the feature that makes it worth paying for

Boring technology on purpose#

At 0-to-1, novelty is a tax. I reach for Postgres, a typed language, and a platform that deploys in one command. The excitement should be in the product, not the infrastructure.

Own the problem, not the ticket#

The difference between a senior engineer and a founding engineer is scope. A founding engineer doesn't ask "what should I build?" — they ask "what does this product need to succeed, and what can I do about it?"

The best founding engineers are annoyed by problems nobody assigned them.

That means talking to users, watching support tickets, and sometimes deciding the most valuable thing you can ship this week is nothing new — just fixing the thing that quietly loses customers.

Leave a trail#

You will hand this codebase to people who weren't there for the decisions. Types, tests at the boundaries, and short design notes are how you compress a year of context into something a new engineer can absorb in a day.

Zero to one is a craft of judgment under uncertainty. The code is just how you write the judgment down.