The number that matters
Not the build cost — the cost of building the wrong thing. Most SaaS MVPs are over-scoped by half. Cutting to the single workflow that proves your idea is worth more than any efficiency in how it gets built.
Written for founders scoping a first version. The cost ranges matter less than the scoping discipline that determines which range you land in.
What a first version actually needs
Version one
- The one workflow that delivers your core value
- Sign-up, login, password reset
- Tenant isolation done properly
- One paid plan, via a payment provider
- Basic usage analytics
- A way for you to support customers manually
Not yet
- Roles and permission matrices
- SSO and SAML
- Public API and webhooks
- Admin dashboard with charts
- Multiple pricing tiers
- White-labelling and custom domains
Every founder builds SSO too early. Enterprise customers who need it will tell you, and they will wait — because their procurement cycle is longer than your development cycle anyway. Building it before you have those customers is spending validation budget on a feature nobody has asked for.
Where the budget goes
| Component | Share | Notes |
|---|---|---|
| Core product workflow | 35–45% | The reason people pay |
| Auth and tenancy | 10–15% | Get isolation right; it is unfixable later |
| Billing integration | 8–12% | Integration, not building billing |
| UI and design | 15–20% | Restraint here saves a lot |
| Infrastructure and deployment | 8–12% | Keep it boring |
| Testing and hardening | 10% | Do not cut this |
Timeline expectations
| Scope | Realistic timeline |
|---|---|
| Single workflow, minimal UI, one plan | 2–4 months |
| Core product with polished UI | 4–6 months |
| Multiple workflows, integrations | 6–9 months |
| Anything described as "like [large competitor]" | Not an MVP |
If your MVP scope reads like a feature list rather than a single sentence about what one user can now do, it is not an MVP — it is version one of a full product with an optimistic name.
The decisions that are expensive to reverse
- Tenant isolation model. Shared database with a tenant column is the right default. Getting this wrong — or forgetting the tenant filter on one query — is the bug that ends SaaS companies.
- What you track for billing. If you might charge by usage later, record usage from day one. Backfilling it is impossible.
- Data model for your core entity. Changing it after customers have data is migration work under pressure.
- Whether you can delete a customer's data completely. Design this in; regulations require it and retrofitting is painful.
Enforce tenant scoping at the framework level, not by remembering to add a filter to every query. One forgotten WHERE clause showing one customer another customer's data is an existential event for a young SaaS company — and it is entirely preventable with a query-layer default.
Where founders overspend
- Custom design systems before knowing whether the product works. Use a component library.
- Building billing rather than integrating a provider.
- Microservices at MVP stage — operational complexity for scale you do not have.
- Admin dashboards when a database client would do for the first fifty customers.
- Optimising for scale you have not reached. You will rewrite anyway once you learn what users do.
- Multiple pricing tiers before understanding what people value.
What not to economise on
- Tenant isolation. Non-negotiable.
- Backups you have tested restoring. Losing customer data is fatal for a SaaS business.
- Basic security — hashed passwords, parameterised queries, HTTPS.
- Analytics. You cannot learn from an MVP you are not measuring.
- Error tracking. You need to see failures users never report.
The costs after launch
| Cost | Frequently forgotten? |
|---|---|
| Maintenance — 15–25% of build annually | Yes |
| Infrastructure, growing with usage | Sometimes |
| Payment processing fees | Sometimes |
| Support — your time initially | Almost always |
| Iteration based on what you learn | Almost always |
That last row matters most. The MVP is not the product — it is how you find out what the product should be. Budget for building the second version.
Scoping a SaaS MVP? Describe the one workflow that proves your idea — if the scope can be cut, we will say so. See our web application service, multi-tenant architecture, and MVP scoping guide.