“Minimum viable” has been read as “cheap and disposable” for so long that founders now budget for the rewrite before they’ve shipped the original. That’s a choice, not a law.
The rebuild is almost never technical
When a product gets rewritten in year two, the reason is rarely the framework. It’s that the data model encoded an assumption about the business that turned out to be wrong: one user per account, one currency, one kind of customer. And every screen inherited it.
Four decisions that survive
- Model the business, not the screens. Get the nouns right: what is an account, an order, a member. Then the UI can change a dozen times without a migration.
- Boring infrastructure. Managed database, managed auth, one hosting platform. Novelty in the stack buys nothing and costs you the whole quarter when it breaks.
- Instrument from day one. If you ship without knowing what people do, your first month of customer data is gone and you can’t get it back.
- Put AI where it’s the point, not everywhere. Inside the product when it’s the reason someone switches; behind it when it saves you a hire. Anywhere else it’s a demo.
What you should throw away
Plenty, just not the foundation. The onboarding flow, the pricing page, half the features: all of that should be cheap to replace, and will be replaced. Build those fast and loose on purpose. The distinction that matters isn’t quality, it’s which parts you’ve committed to.
The test
Before we ship anything, we ask one question: if this works, what breaks first? If the answer is “the code,” we didn’t build it properly. If the answer is “we’ll need to hire,” we built the right thing.
