Everyone who built their MVP "fast and cheap" is now on their second build. The rewrite costs 3x the original and takes 8–18 months you didn't budget. You can avoid it, but only if you make three specific architecture decisions in month one — and only if you understand why those three and not the other hundred.
The pitch you'll hear everywhere is: move fast, validate the hypothesis, worry about the architecture later. That pitch is half-right. Move fast, yes. Validate the hypothesis, yes. But "worry about architecture later" assumes the architecture decisions can be deferred. Most of them can. Three of them can't.
What the rewrite actually costs
The median early-stage rewrite costs $150k–$300k in engineering spend and a year of competing priorities. That's the financial number. The real cost is what you're not building during that year.
The companies that avoid the rewrite aren't the ones that built slower. They're the ones that built the same speed but made the right three calls in week one. The minimum viable architecture and the minimum viable feature set are not in conflict — they're both constraints on the same build, and getting both right is the thing that makes the first version actually viable.
The companies that rewrite usually know they're heading there at month six. The codebase is working but every new feature takes longer than the last. The data model has implicit constraints managed in application code. Adding a field to a core table breaks something unrelated. The team knows the system is fragile but the business pressure to ship features is higher than the engineering pressure to fix the foundation. Then at month 12 or 18, the weight becomes intolerable and the rewrite happens.
The three decisions
1. The data model
The data model is the decision that can't be undone cheaply. You can rewrite application logic relatively quickly. You can swap libraries, refactor modules, change API shapes. You cannot change a schema that's wrong without touching every query, every ORM model, every migration downstream, and every test that touches data.
The minimum required for an MVP data model:
Model the domain, not the features. The schema should reflect what your business domain actually is — the entities, their relationships, their invariants — not a direct translation of the v1 feature list. A user management table that only supports one role per user, because v1 only has one role, is a feature-shaped decision. A user management table that supports a roles array, even if v1 only ever writes one value to it, is a domain-shaped decision. The second schema costs about 10 minutes more to write and buys you a year.
Enforce constraints at the database level. Foreign keys, non-null constraints, unique constraints — these aren't premature optimization, they're correctness. The discipline of making the schema enforce the business rules means application bugs that violate data integrity fail loudly rather than silently corrupting records. Silent corruption is the worst kind of bug: it accumulates for months before you notice.
Write migrations with the next migration in mind. Before you add a column, ask: what's the next state of this table? If you're adding plan_type: string to the users table, and you know you'll eventually need plan versioning, model it as a relationship from the start. Not the full version history — just the relationship. The column is for now; the schema is for the next 18 months.
2. Auth and multi-tenancy
Auth is the most commonly under-specified thing in an MVP spec. The spec usually says "users can log in." The architecture decision is: who are the users, what can they see, and what will the permission model look like when you have enterprise customers?
For most B2B SaaS products, the answer to "what will the permission model look like?" includes organization-level isolation, multiple roles within an organization, and eventually some form of SSO. None of these are features you add later to a single-tenant, single-role system without significant migration work.
The minimum viable auth architecture:
Design for organizations from the start. Even if v1 has no concept of teams, the schema should have an organizations table and users should belong to organizations. This costs one migration and one model. Not doing it costs a partial rebuild when your second enterprise customer has multiple users.
Role as a field, not a boolean. is_admin: boolean is the most common auth shortcut and the most painful one to undo. role: string with a default of user takes the same time to write and supports every role model you'll ever need.
Never build auth from scratch. Use a maintained auth library or service for session management, token handling, and password security. The custom auth decision is almost always a mistake — not because it's difficult, but because it requires ongoing maintenance of security-critical code that isn't your product. This is the one place where "use the library" is the unambiguous call.
3. API structure
The API is the contract between your current frontend and your current backend. The mistake is designing it as if it's only that.
The minimum viable API structure:
Version from day one. /api/v1/ costs nothing to add and means that when you break backward compatibility — and you will — you can do it without breaking existing clients. If you have mobile clients or third-party integrations in your product roadmap, this isn't optional.
Design the resource model before the endpoints. The API should reflect the domain model, not the current frontend's needs. An API that has endpoints for every page's specific data requirements becomes unmaintainable the moment the page changes. An API that has endpoints for resources — users, organizations, projects — can serve every page and every future integration.
Error responses are part of the contract. Consistent error codes, consistent error shapes, meaningful error messages. Not for the developer experience — for the reliability of any client that consumes the API. An API that returns a 200 with an error in the body is an API that's impossible to build reliable error handling against.
Why these three and not the other hundred
There are hundreds of architectural decisions in any non-trivial build. Most of them are reversible or cheap to change. API middleware, caching strategy, queue implementation, service organization — these can be changed without touching the foundation.
The data model, auth, and API structure are the three that touch everything else. A schema change affects every query, every model, every migration, every test. Auth is threaded through every request, every data access, every permission check. The API contract is the boundary everything else builds against.
Get these three right — not perfect, right — and you can change everything else. Get them wrong and you're rebuilding.
What "right" means at MVP scale
Right at MVP scale doesn't mean enterprise-ready. It means future-proof enough that the next 18 months of features don't require undoing the foundation.
For the data model: the schema reflects the domain model, enforces constraints at the database level, and can accommodate the most likely 18-month product evolution without a breaking migration.
For auth: organizations exist in the schema, roles are modeled as roles not booleans, and session management uses a maintained library.
For the API: resources are versioned, the resource model reflects the domain, and error responses are consistent.
That's it. Not microservices, not event sourcing, not a distributed system. A monolith with a sound foundation.
The sophisticated thing about this approach is that it's cheap. The three decisions above add maybe 2–3 days to a 90-day MVP build. The rewrite they prevent costs $150k–$300k and 8–18 months.
What this looks like when it's resolved
You're 18 months post-launch, your first enterprise customer wants multi-user support, and the migration takes three days. Not three months — three days. Because the organizations table was there from the start.
You're adding a new user role for a permissions model you couldn't have anticipated at v1. It takes an afternoon, because role is a string, not a boolean.
Your second developer joins the team and contributes a meaningful feature in their first week, because the schema is documented and the API contract is explicit.
A potential acquirer's engineer reads the codebase and comments that the data model is well-designed. Not because you built a cathedral — because you made the right three calls at the start.
That's the state you're building toward. Not perfection. Not over-engineering. A foundation that doesn't fight you.
This is for you if
You're a pre-seed or seed founder building your first platform. You have a feature list, a hypothesis you need to validate, and a budget between $25k–$100k. You've heard the pitch about moving fast and you know it's right — you just also know that the companies you've watched struggle usually trace the struggle back to a decision made in month one.
The engagement starts with a scoping conversation about your domain model, your user model, and your 18-month product direction. The deliverable is a working MVP with a foundation that survives growth.
This is not for teams that want a feature factory. If the goal is the cheapest possible thing that works for three months, there are cheaper options. This is for founders who want to build once — not twice.
The cost of doing this right at the start is a rounding error on the cost of the rewrite you're avoiding.