An MVP has one job: to verify that somebody will pay. Anything that does not serve that verification is wasted time. But between "moving fast" and "building carelessly" there is a line, and it sits in specific places.
What you can legitimately rush
At the start, these shortcuts are healthy:
- The back office. An ugly admin interface will serve you perfectly well for a year. No outsider sees it.
- Automating rare cases. If three customers a month need special handling, do it by hand. Automating too early freezes a business rule that is about to change.
- Scaling. A single server handles thousands of users. Designing for a million when you have zero is the most expensive form of procrastination.
- A complete design system. Five well-made components are enough early on.
The three decisions you cannot undo
Three choices, however, structure everything else. Postponing them costs a rewrite.
1. The data model
This is the point of no return. If you start with a user belonging to a single organisation, and six months later a customer wants to manage three subsidiaries, the migration touches every query in the application.
Ask the question on day one: who owns a record? A user, a team, an organisation? Even if you only sell to freelancers at first, an organisation identifier present from the start costs almost nothing and avoids the worst.
2. Authentication and permissions
Adding roles afterwards means rereading every controller and asking "who is allowed to do this?". Even a minimal authorisation layer (two roles is enough) installs the habit and the place to write it down.
3. Tests on the critical path
Not 100% coverage; that would be absurd at this stage. But sign-up, payment and the product's main action must be covered. Those are the three journeys whose failure costs you customers, and the ones you will change most often.
The turning point
Moving from MVP to product rarely hinges on technology. It hinges on the moment support starts taking more time than development.
Signals to watch:
- you answer the same question several times a week;
- you fix data by hand in the database;
- a new feature systematically breaks something old.
The first signal calls for documentation or an interface change. The second, an admin tool. The third, tests, and that one is the most urgent, because it slows everything else down.
In practice
An honest MVP takes six to ten weeks. The product that follows is built continuously, in short increments, with users who see every release.
What separates projects that last is almost never technical sophistication at the start. It is having had, from day one, a data model that honestly reflects the business.
