What drives the cost of a SaaS MVP

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. All four assume the decision to build has already been made — if a configurable product already covers the workflow you intended to charge for, the cheapest MVP is the one you never build, which is the comparison in build or buy, applied per process.

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.

Where the budget actually goes

An indicative split for a typical first release with a three-person team over eight 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.

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.

1. Two flat plans instead of usage-based billing. Add metering once you know what is worth metering.
2. Owner and member roles only. Custom roles become a paid upgrade when a customer asks.
3. One integration, chosen by which one closes deals. The rest wait for demand.
4. A basic internal admin rather than a polished one. Ugly and functional beats absent.
5. Manual onboarding for the first customers. It does not scale, and for the first twenty it does not need to.
6. Responsive web before a native app. A mobile app is a second product with its own release cycle, and most first releases do not need one — one question settles whether yours does, and it is worth answering with usage data rather than in the kick-off meeting.

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.

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, and fixed price or time and materials for how each contract shape behaves once the scope starts moving, which on a first release it will.

Questions

What founders ask before approving the budget

What does a realistic first-release budget actually buy?

Eight to twelve weeks with a three-person team, working in two-week sprints with a demo you can use at the end of each one. That buys one core workflow at production quality, multi-tenancy with row-level isolation, sign-up and invitations, two flat Stripe plans with the entitlement table held in your own database, an internal admin console, infrastructure as code with a staging environment, and automated tests around the paths that move money. It does not buy usage metering, single sign-on, a public API or a mobile app. Those are second-release decisions, and treating them otherwise is how a fixed budget becomes a late one.

Why do two quotes for the same brief differ by a factor of two?

Usually because one team priced the brief and the other priced the operational surface behind it. The lower number tends to omit the admin console, the staging environment, migration of the data sitting in a spreadsheet, and the tests that let you deploy without a rollback rehearsal — none of which appear in the brief. Put the same five questions to both: which tenancy model, which billing shape, how many roles, which integrations, and what is explicitly out of scope. The gap usually becomes explainable. If a budget is fixed we will cut named scope to meet it; we will not quietly remove the tests to win on price.

Should billing go into version one, or can metering wait?

Build billing in version one and defer metering. The expensive thing to retrofit is not taking the payment — it is the entitlement layer that decides what a given tenant is allowed to do, because eventually every screen reads from it. Put that in your own database from the start and let Stripe Billing handle plans, proration, trials and dunning. Metering is a different problem: it needs a unit customers accept as fair, and you learn that from real usage rather than from a workshop. We ship that table in the first release even where a client wants billing switched off until launch week, because it is the one part of billing that is cheap now and expensive later. With entitlements already in place, adding a metered plan is an addition rather than a rewrite.

What happens to the cost when the first enterprise buyer asks for SSO?

It depends on whether the identity model anticipated it. If users belong to a tenant and authentication is already a separate concern, adding SAML or OIDC single sign-on with role mapping is discrete work measured in weeks. If every user is a row with a password and a tenant column, it touches every authenticated path and the number is unpleasant — which is why we architect for it and implement when the deal is real. SSO rarely arrives alone: audit export, session policy and a security questionnaire come with it. Worth saying plainly, we are not ISO 27001 or SOC 2 certified, and neither is your product for having added SSO.

We already have Figma screens. Does that reduce the price?

Less than most founders hope, and the reason is worth knowing before you commission more of them. A designer works with the team through the first half of the build either way, and what that person spends time on is the states a concept file rarely contains: empty, loading, error, permission denied, half-synced, and what a second role sees on the same page. Hand us forty polished happy-path screens and we still have to draw those. What genuinely takes cost out is decisions rather than pixels — a named primary user, the one workflow that must work, which fields are actually required. A file that settles those shortens discovery. A visual concept produced before anyone answered them is a mood board, and we will say so rather than bill you for agreeing with it.

What does it cost to run per month once it is live?

It starts the week you deploy, not the week you become profitable, and for most first releases it is a few hundred dollars a month rather than a few thousand. A single-region deployment — managed Postgres, one or two small application instances, object storage and a CDN — is dominated by the database; the application servers are close to noise. Error tracking (Sentry), transactional email via Postmark or Amazon SES, and log retention usually sit on entry tiers well past your first hundred customers. The one line that scales with success is Stripe's per-transaction percentage, which is a cost of revenue and belongs in your pricing, not your infrastructure budget. What we will not do is spend build budget tuning a bill this small: at first-release scale the levers in where cloud spend actually leaks — idle non-production environments, cross-zone transfer, log retention — return less than the same week of engineering spent on the product, and they will still be there when the bill is worth the effort.

Published: 23 August 2026 Last updated: 2 September 2026 Written by Canopus delivery team