Your MVP can survive production. Here's how.

There's a comfortable myth in startup land: build a scrappy MVP, validate, then 'rewrite it properly later.' The rewrite almost never comes — the product is live, users are on it, and the scrappy code is now the critical path for the company.

The founders who avoid that trap don't build more. They build differently. An MVP that survives production is a question of discipline, not budget.

Scope is a strategy, not a compromise

The difference between a demo and an MVP is what you refuse to build. A demo shows off features. An MVP shows a complete, working loop — one real user, one real problem, one real outcome — with every edge case that loop needs to function in the wild.

• Define the single job-to-be-done your first users will pay for.
• List everything outside that loop and deliberately cut it.
• Treat 'boring' quality as in-scope: error states, empty states, slow-network behaviour.
• Ask one question per build cycle: does this make the loop faster or more reliable?

Architecture you won't be ashamed of in a year

MVP architecture doesn't mean no architecture. It means the smallest architecture with a future. A few rules we follow: the data model is designed for the product you'll have in a year, not the feature you're demoing this week. Third-party integrations sit behind interfaces so they can be swapped. And every table gets the timestamps, indexes and audit fields you'd want when things go wrong.

Build the smallest thing that is still the real thing.

Ships in weeks, learns in weeks

The real advantage of a disciplined MVP is velocity of learning. If you can ship in weeks, you can iterate in weeks. Each cycle of user feedback tightens the loop, and by the time you hit production traffic, the product isn't a guess anymore — it's a response to evidence.

That's the entire game: get the loop tight early, and the scale story takes care of itself.