Most first versions fail for the same reason: they are not minimal. The feature list came from imagining every future customer instead of serving the first ten.
The test for what belongs in version one
One question: does removing this stop the core job from being done? If the answer is no, it waits. Not "it is quick to add", not "customers will expect it". It waits, and real usage decides whether it ever arrives.
Applied honestly, this usually removes a third of the backlog before a line of code is written.
What can almost always wait
- Multiple pricing tiers. Launch with one and learn what people will pay for.
- A public API. Build it when a customer asks with a signed contract.
- Deep customisation and white-labelling.
- Native mobile apps, if the web version works well on a phone.
- An analytics dashboard for users. You need analytics; they usually do not, yet.
What is never optional
Authentication done properly. Password reset, sessions, and roles from the start. Retrofitting a permissions model into a live product with customer data is one of the most expensive things you can do.
Billing that reconciles. Even with three customers, subscriptions, invoices and failed payments need to work. Manual invoicing does not survive the transition to thirty customers, and the transition is not gradual.
Data separation between tenants. One customer seeing another customer's data is not a bug you recover from commercially. This is an architecture decision made on day one, not a check added later.
Backups you have restored. Not backups you have configured. Restored, at least once, verified.
Regional specifics worth planning for
If you will invoice in the UAE or Saudi Arabia, VAT and e-invoicing requirements affect how you store invoice data. Retrofitting compliant invoicing is far more painful than designing for it. And if you intend to sell to government-linked entities, ask early about data residency, because it can determine your hosting choice.
How long an MVP should take
Eight to sixteen weeks. If your plan runs longer, the scope is not minimal. The purpose of a first version is to be corrected by reality as quickly as possible, and every extra month delays that.
Frequently asked questions
Should I use no-code for the MVP?
For validating demand, often yes. For anything with real multi-tenant data or complex permissions, you will hit the ceiling and rebuild, so factor that in rather than being surprised by it.
How much should a SaaS MVP cost?
It depends entirely on the core job. The useful discipline is to fix the budget and the timeline, then cut scope to fit, rather than fixing scope and letting the other two drift.
