Shipping the messy first version

The first version of a product is almost never the version you imagined in the pitch deck. That's not a failure of planning. It's how building actually works.

I've spent most of my career in the messy middle: early products, evolving teams, requirements that change mid-sprint, and customers who tell you what they want only after they've used what you built. The teams that ship well aren't the ones with the cleanest initial spec. They're the ones who know how to build something useful before they build something perfect.

Useful beats perfect

Perfect is a trap in 0→1 work. Perfect assumes you know what the product should be. Early on, you don't. You have hypotheses. The job of v1 is to test them with real usage, not to impress anyone with architectural elegance.

That doesn't mean sloppy. It means focused. A messy first version that solves one real problem for one real user is worth more than a polished demo that solves nothing.

When I join early-stage builds, I ask three questions before writing code:

1. What is the smallest thing we can ship that a real person would use tomorrow?
2. What are we explicitly not building in v1?
3. What would we need to see from users before we invest in the next layer?

Those questions keep the team honest. They also prevent the most common early-stage mistake: building infrastructure for a product that doesn't exist yet.

Messy is a feature, not a bug

Unclear requirements aren't a sign that the team is disorganized. They're a sign that the problem space is still being discovered. The founding engineer's job isn't to eliminate ambiguity. It's to build systems that can absorb change without collapsing.

That means:

• Modular where it matters, not everywhere
• Clear boundaries between what's stable and what's experimental
• Honest documentation of tradeoffs, even when they're uncomfortable
• Fast feedback loops so wrong assumptions get corrected quickly

I've seen teams spend months on a "scalable architecture" for a product with zero users. I've also seen teams ship a scrappy v1 in weeks and learn more in a month than the first team learned in a year.

When is it "real"?

A product becomes real when someone other than the builder depends on it. Not when the landing page looks good. Not when the pitch deck says "launched." When a user would be genuinely inconvenienced if it went away.

That's the bar I hold myself to. Ship the messy first version. Make it useful. Then make it real.

Requirements may change. That's why we build calmly.