We've inherited a lot of rewrite projects. The pattern is almost always the same: a team moved fast, kept scope tight, shipped something real — and then the product found traction. What worked at 50 users became a liability at 5,000. The code that was "good enough for now" turned out to be load-bearing in ways nobody expected.
The rewrite that follows typically costs 2–3× the original build and takes twice as long, because the team now has to maintain the old system while building the new one. The cheap MVP was not cheap.
What people get wrong about "fast"
Speed in an MVP context means time-to-learning, not time-to-code. The goal is to answer a question: does this product solve a real problem for real people? Every technical decision should be evaluated against that goal.
Where teams go wrong is conflating "fast" with "disposable." A disposable codebase — no types, no tests, no documented data model, coupled business logic — is fast to write and slow to change. Because change is what you're about to do a lot of.
The tradeoff isn't between fast and good. It's between fast-to-write and fast-to-change.
The three decisions that haunt you
Most rewrites trace back to one of three early decisions:
- Data model: Denormalised tables or document stores chosen for development speed make queries painful and migrations expensive once relationships get complex. A little upfront normalisation buys enormous flexibility later.
- Auth and multi-tenancy: Bolting on teams or org-level isolation after launch is a full data-model rework. If there's any chance you're building a B2B product, design for multi-tenancy before you write the first query.
- Coupling business logic to the delivery layer: Business rules buried in API route handlers or UI components can't be tested, can't be reused, and can't be moved when you add a new surface (mobile app, webhook, background job).
These aren't "nice to have" architecture concerns. They're the things that make growth feel smooth or feel like walking through mud.
What a well-structured MVP actually looks like
You don't need microservices. You don't need a monorepo with six packages. A well-structured MVP is a monolith with clear internal boundaries: a thin API layer that delegates to service functions, a service layer that contains business logic, and a data layer that owns queries. That's it.
This structure adds perhaps two days to an initial build and saves weeks on the first major feature change — because you can find, test, and modify logic without reading the entire codebase first.
The real scope lever is features, not quality
If the timeline is fixed and the team is fixed, the lever is feature scope — not code quality. Cutting a feature is always faster than cutting architectural rigour, and architectural decisions are much harder to undo than feature gaps are to fill.
A useful rule of thumb: if you're not prepared to maintain this code in production for 18 months, you should either cut the feature or do it properly. "We'll fix it later" almost never happens; "later" arrives full of new features and nobody has time.
Build MVPs that you can extend, not ones you have to escape.
Founder
Got an idea? Let's ship it.
Tell us what you're building. We'll come back with a clear scope, a real timeline, and the senior team who'll actually build it.