The Second Version
10 March 2026
The last line of my previous post on shipping was: "The second version will be better anyway."
I wrote it as a consolation — a way to make the imperfection of a first release easier to swallow. But the more I think about it, the more I think it undersells what actually happens after you ship.
The second version isn't just better. It's a different kind of work.
What the first version actually is
The first version of anything is a hypothesis. You've made a series of decisions — what to build, what to include, how it should work — based on your best guess about what users need. Some of those guesses are right. Most are partially wrong. A few are completely wrong in ways you couldn't have anticipated.
You don't know which is which until real people use it.
That's not a failure of planning. It's the nature of building software for other humans. No amount of research, user interviews, or design work fully substitutes for watching someone actually use what you built. The map is never the territory.
The first version's job is to make contact with reality. That's it. Everything else — the architecture, the polish, the features you agonized over — is just the cost of admission.
The signal that comes back
When Barba Studio launched, I expected complaints about the calendar UI. I'd rushed it and knew it wasn't great. What I actually got: nobody mentioned the calendar. What they mentioned was appointment reminders — specifically, that they wanted to customize the message text.
I had built a reminder system. It worked. But I'd made the message a fixed template because customization felt like scope creep at the time. To every user, that fixed template was the first thing they wanted to change.
That's the kind of signal you only get from shipping. It's not that I couldn't have thought of message customization in advance — I probably could have. But I would have ranked it lower than ten other things, and I would have been wrong. The user told me exactly what to build next.
The second version isn't guessing. It's responding.
Building with signal vs. building in the dark
Most of the work before a first launch is building in the dark. You're making decisions without feedback, without usage data, without knowing which parts of what you built actually matter to anyone. It's necessary — you have to start somewhere — but it's also expensive. Every hour you spend on the wrong feature is an hour you can't recover.
After launch, that changes. You have data. You know what's being used and what isn't. You know where people drop off. You know what they ask for. The decisions you make in the second version are grounded in something real.
This is why I've come to think the first version of a product isn't really the beginning of building it. It's the end of the research phase. The building starts in earnest with the second version.
When to start
Not immediately.
There's a window after launch where you're flooded with initial reactions — some useful, some noise, some contradictory. Jumping straight into the second version based on that first wave is a mistake. You're reacting to incomplete data before it's had time to settle.
What I do: I let the product run for a few weeks. I collect everything — support messages, conversations, usage patterns if I have instrumentation. Then I sit with it and look for patterns. Not individual requests — patterns. The features that multiple different people ask for in different ways. The friction points that show up again and again. The things nobody mentions that I expected to be important.
That pattern recognition is where the second version's scope comes from.
What changes, what doesn't
The second version is usually more focused than the first, not bigger. The first version is often too broad — you built for hypothetical users, so you covered a lot of ground defensively. The second version can be narrower because you know which ground actually matters.
What changes: the things users told you. What doesn't: the things users didn't mention. If nobody complained about the onboarding flow, the onboarding flow is probably fine. Ship it again.
This sounds obvious, but the temptation is to use the second version as an opportunity to fix everything you didn't like about the first. That's how second versions become their own perfection trap. The discipline is the same as before: let the signal drive the scope, not your own taste.
When there is no second version
Sometimes a product doesn't generate enough signal to build a second version from. People use it once, don't come back, don't say why. That's data too — possibly the most important data you can get.
A lack of engagement isn't a reason to iterate. It might be a reason to rethink, or to stop, or to ask harder questions about whether the thing you built solves a real problem for real people. No second version is better than a second version that doubles down on a first version nobody wanted.
The second version being better isn't automatic. It's conditional on the first version teaching you something. If it didn't, the work isn't iteration — it's something else.
Ship the first version to learn. Build the second version from what you learned. That's the whole loop.