What drives the cost of a SaaS MVP
Quotes for the same brief can differ by a factor of two, and it is almost never because someone is guessing. Four decisions set the number before anyone writes code. If you understand them, you can steer the budget instead of negotiating blind.
A SaaS MVP is priced by its operational surface, not its screen count. Four decisions do most of the work: how many roles the product has, whether billing is flat or usage-based, what it must integrate with, and whether an enterprise buyer arrives in year one. Everything else is comparatively predictable.
The four decisions that move the number
Founders scope screens. Budgets are consumed by everything around them. These four are settled during discovery, and each one is a genuine choice rather than a fixed cost.
1. How many roles the product has
A single-role product — every user sees the same thing — is the cheapest SaaS you can build. The moment you add an admin who manages other users, a billing contact who is not the owner, or a read-only auditor, you are building role-based access control, an invitation flow, and a permissions matrix that has to be tested against every screen. Roles multiply test surface faster than any other feature.
2. Whether billing is flat or usage-based
Two flat monthly plans through Stripe Billing is a small, well-understood piece of work. Usage metering, overage, proration on mid-cycle upgrades, trials, coupons and dunning for failed cards is several times that — and it is the area where getting it wrong costs real revenue rather than just looking untidy. Most products do not need metering in version one.
3. What it has to talk to
A self-contained product is straightforward. One integration with a system of record — a CRM, an accounting package, a carrier API — adds meaningful time, and that time usually depends on the other side's sandbox access rather than on our development. Integration is also the area most likely to slip for reasons nobody controls; we explain why in why integrations fail silently.
4. Whether an enterprise buyer arrives in year one
SAML single sign-on, audit export, data residency options and a security questionnaire arrive together, usually attached to your first large customer. Building them into the MVP is expensive. Building them after a prospect asks is worse, because it happens under deal pressure with a date attached. The honest middle is to architect for them and implement when the deal is real.
Cost tracks the operational surface — roles, billing edge cases, integrations, enterprise controls — far more than the number of features. Two products with identical screens can differ enormously on these four axes.
Where the budget actually goes
An indicative split for a typical first release with a three-person team over ten to twelve weeks. Proportions move by project, but the shape is remarkably stable — and it surprises most founders, because the visible product is well under half of it.
| Area | Share | What it covers |
|---|---|---|
| Discovery & architecture | 10–12% | Specification, data model, tenancy decision, costed plan |
| Core workflow | 30–35% | The one thing customers pay for, at production quality |
| Tenancy, auth & roles | 15–18% | Row-level isolation, sign-up, invitations, permissions |
| Billing & entitlements | 10–15% | Stripe plans, webhooks, the entitlement table you own |
| Admin & support tooling | 8–10% | The console your own team runs the business from |
| Infrastructure & CI/CD | 8–10% | Infrastructure as code, staging, pipelines, monitoring |
| QA & launch hardening | 8–10% | Automated tests, load check, rollback plan, handover |
Scroll the table sideways for the full breakdown.
Read that table again with one thing in mind: the core workflow — the part a founder would describe as "the product" — is roughly a third. The rest is what turns an application into a business you can operate and sell.
Four costs founders forget
- The admin console. Every SaaS needs a way for your own staff to see tenants, fix data and answer support questions. Skip it and every support ticket becomes a developer task — which is far more expensive than the console would have been.
- Running costs from day one. Cloud, payment processing fees, error tracking, email delivery. Modest at launch, but they begin the week you deploy, not the week you turn a profit.
- The second release. An MVP earns feedback, and acting on feedback needs budget. Plan a meaningful reserve for the three months after launch, or the product stalls exactly when it is learning fastest.
- Migration off the prototype. If there is an existing spreadsheet, Airtable or no-code version holding real customer data, moving that data is its own priced task. It is routinely assumed to be trivial and routinely is not.
What we would cut to reach a lower number
When a budget is tighter than the brief, these are the cuts we recommend — in this order, because each one is reversible later without a rewrite.
- Two flat plans instead of usage-based billing. Add metering once you know what is worth metering.
- Owner and member roles only. Custom roles become a paid upgrade when a customer asks.
- One integration, chosen by which one closes deals. The rest wait for demand.
- A basic internal admin rather than a polished one. Ugly and functional beats absent.
- Manual onboarding for the first customers. It does not scale, and for the first twenty it does not need to.
What we would not cut: multi-tenant isolation enforced at the database level, automated tests, and infrastructure defined in code. Those three are the ones that force a rewrite when skipped — the reasoning is set out in how we build SaaS platforms.
Two products with the same feature list can differ by a factor of two on the four decisions above. A headline figure would be wrong for most readers, and the ones it fitted would still need a specification before it meant anything. We quote after a paid discovery phase, and the specification it produces is yours whether or not you build with us.
How to get a real number for your product
Two answers determine most of the estimate: who pays, and what they pay for. Those decide the tenancy model, the billing shape and roughly half the architecture. Send them along with a description of the one workflow that must work, and you will get a considered response rather than a calendar link.
If the requirement is still forming, that is normal and it is what discovery is for — see engagement models for why fixed price on an unknown tends to cost both sides more.
Related reading
Tell us who pays, and what they pay for.
Those two answers decide the tenancy model, the billing shape and half the architecture. An engineer replies within one business day with the trade-offs as we see them.
- Email — [email protected]
- Phone / WhatsApp — +91 817 979 7732