Scope is the shortcut. Quality is not.
The point of an MVP is to test an assumption with the least work. Teams get into trouble when they translate "least work" into "lower engineering standards" rather than "fewer features".
Cutting features is reversible. You add them later. Cutting the things that make a codebase changeable is not: you pay for it in every sprint that follows.
Safe to defer
Early on, these can wait without hurting you later.
- Breadth of features — one workflow done well beats five done partially
- Admin tooling — a database client and a runbook is fine at first
- Horizontal scale — one well-sized server carries you further than most expect
- Custom design systems — a good off-the-shelf component library is enough
- Micro-optimisation — measure before you tune anything
Expensive to defer
These are the ones that compound. Skipping them buys a few weeks and costs months.
- A sane data model — schema mistakes propagate into every query, screen and report
- Authentication and authorisation boundaries — retrofitting these touches everything
- Automated deployment — manual releases stay manual, and get scarier over time
- Basic test coverage on core flows — not everything, but the paths that lose money when broken
- Observability — you cannot fix what you cannot see, and outages arrive at the worst moment
The rewrite trap
When an MVP succeeds, the pressure is to keep adding to it. When it was built without the items above, the team eventually argues for a full rewrite instead — usually right when the business can least afford to pause.
The goal is not a perfect first version. It is a first version you can keep building on.