Most advice about MVPs tells you to cut features. The harder decision is which technical choices you can safely postpone, and which will force a rewrite in eighteen months.
“Build it fast and rewrite it later” is reasonable advice that is applied too widely. Some shortcuts are genuinely cheap to undo. Others quietly become the reason a growing company spends six months rebuilding instead of releasing new features.
Safe to postpone
- Scaling across many servers. A single well-specified server handles far more than most founders expect.
- Microservices. A well-organised single application with clear internal boundaries is easier to split later than a distributed system is to merge.
- Custom infrastructure. Use managed services until the bill justifies the engineering time.
- Sophisticated caching. Add it once you have measured a real problem.
Expensive to undo
- Your data model. Getting the core entities and their relationships wrong affects every query, report and integration.
- User accounts and tenancy. Adding support for multiple customer organisations to a system built for one is among the most expensive changes there is.
- Audit trails. You cannot recreate history you never recorded, and regulators will ask for it.
- How records are identified. Changing the type of your primary keys after launch affects everything.
The practical rule
Take architectural care over anything that writes to the database or controls who can see what. Move quickly everywhere else. That balance lets you launch in twelve weeks without a rewrite waiting for you at the end.
TopicsArchitectureStartupsMVP