Engineering
Choosing a stack for an MVP you will not have to rewrite
By Zettops. Published · 3 min read
Most MVP rewrites are not caused by the framework. They come from a few early decisions about data, auth, and structure that are hard to undo.
An MVP should be quick to build, but it should not be a dead end. The good news is that avoiding a rewrite has less to do with picking the perfect framework and more to do with a few choices that are expensive to change later.
The rewrite is rarely about the framework
When teams rebuild an early product, the reasons tend to be structural: a data model that cannot represent how the business actually works, authentication bolted on in a way that cannot support teams or roles, or logic spread across so many services that nobody can change one thing safely.
A popular, well-supported framework in a language your team knows will usually carry you a long way. Spend your attention on the parts underneath it.
What to optimize for
For an MVP we weigh options against a short list:
- Speed of change: how quickly can one developer ship a feature end to end?
- Hiring and handover: can someone new read the code and be productive soon?
- Operational load: how many moving parts must be kept running, patched, and monitored?
- Security defaults: does the stack make the safe path the easy path?
- Room to grow: can it handle more users and features without a structural change?
Notice that raw performance is not near the top. Most early products are limited by how fast they can learn, not by how fast the server responds.
Common shapes, compared
| Shape | Good for | Watch out for |
|---|---|---|
| Static site with serverless functions | Content-led products, marketing sites, simple forms and APIs | Long-running jobs, heavy real-time features |
| Single web app with a relational database | Most SaaS products, dashboards, marketplaces | Letting one codebase grow without clear modules |
| Microservices from day one | Rarely right for an MVP | Operational overhead, distributed bugs, slower iteration |
| No-code or low-code tools | Validating demand before writing code | Data portability, access control, limits you hit later |
This site is an example of the first shape: a static export on Cloudflare Pages, with Pages Functions and a D1 database for the contact form and admin. For a product with accounts, billing, and a lot of business logic, we would usually reach for the second.
Boring choices that age well
Our defaults are deliberately unexciting:
- TypeScript across the front end and back end, so types catch mistakes at the boundaries.
- A relational database such as PostgreSQL or SQLite, because most business data is relational and benefits from constraints.
- One repository with clear folders for each area of the product, instead of many services.
- Schema validation on every input, so the shape of data is checked where it enters.
- Managed hosting with preview deployments, so every change can be reviewed live before it ships.
None of this is novel. That is the point: well-trodden tools have documentation, answers, and people who already know them.
Tip: if a technology choice needs a long explanation of why it is worth the risk, it probably belongs in a later version, not the MVP.
Decisions that are expensive to change
These deserve a real conversation before you write much code:
- The data model. Sketch the core entities and how they relate. Ask whether a user can belong to more than one organization, because adding that later touches everything.
- Authentication and roles. Use a proven auth approach, and design for roles even if you only have one today.
- Identifiers. Decide how records are identified and whether IDs are ever exposed in URLs.
- Where data lives. Hosting region and data residency are hard to move once customers depend on them.
- Boundaries in the code. Keep billing, auth, and core domain logic in separate modules, even inside one app, so each can change on its own.
Get these roughly right and almost everything else can be refactored in small steps as you learn.
Where to start
Write down the five decisions above for your product, even in a few lines each, before choosing a framework. If you want a second opinion on the plan, or a team to build it, see our full-stack development service, browse the concepts on our work page, or start a conversation.