SaaS development cost: the decisions that set the number
A SaaS product costs more to build than the same screens built once, and the difference is in parts the demo never shows. The same decisions also set what it costs to run every month after launch.
The short version
- The expensive parts of a SaaS product are the ones a demo does not show: keeping customers’ data apart, billing, single sign-on, support access and data export.
- The tenancy model sets the running cost. Microsoft’s architecture guidance puts it plainly: if one customer’s dedicated infrastructure has a cost, a hundred customers probably cost a hundred times that.
- Sharing infrastructure lowers cost and raises other risks: one customer slowing the rest, or one fault reaching every account. Most products mix the two.
- Enterprise buyers bring their own requirements, such as single sign-on, audit logs and a security review. Decide which of them the first version needs before you ask for a quote.
- A quote that does not say how tenancy, billing and identity were priced has priced a different product from the one you described.
Summarise with AI
ChatGPT
Claude
PerplexityWhy a SaaS product costs more than the same screens built once
SaaS development cost is set less by the number of screens than by a handful of decisions: the tenancy model, billing and plans, identity and single sign-on, roles and support access, the assurance customers will ask for, and who runs the product after launch. The tenancy model also sets what the product costs to run every month.
Show a SaaS product in a demo and it has one customer, one plan and one administrator. Run it for a year and it has hundreds of accounts that must never see each other’s data, customers upgrading mid-month, failed card payments, a support team that needs to look inside an account safely, and an enterprise buyer asking for single sign-on and an audit log.
None of that shows on a screen, and all of it has to be built. It is why two quotes for what looks like the same product can be far apart: one priced the screens, the other priced the product. The general reasons quotes differ apply here too. This article covers what is particular to SaaS.
One disclosure before the rest. We build SaaS products for a living and we do not publish prices, for the reasons this article sets out. The architecture guidance below is quoted from Microsoft and Amazon Web Services rather than from our own projects.
The tenancy model sets the running cost
A tenant is one customer account and everything that belongs to it. The first decision in any SaaS product is how much those tenants share. Amazon’s SaaS guidance names the patterns: in the silo model each tenant gets dedicated resources, in the pool model tenants share them, and in the bridge model some parts are siloed and others pooled.
Microsoft’s architecture guidance is direct about what this does to cost. Avoiding sharing feels safer, it notes, but that approach quickly becomes expensive as you add tenants. For fully separate deployments per customer, it says, cost efficiency is low: if a single tenant requires a specific infrastructure cost, a hundred tenants probably require a hundred times that cost.
| Model | Cost | What it protects | What it risks |
|---|---|---|---|
| Separate deployment per customer (silo) | Highest: infrastructure and upkeep grow with every customer | Data isolation, and one customer cannot slow another | Updates and maintenance repeated across every deployment |
| Shared by every customer (pool) | Lowest to run, one set of infrastructure | Simple to update: one deployment | Data leaking between tenants if the code gets it wrong, one heavy customer slowing the rest, one fault reaching everyone |
| Mixed (bridge) | Between the two | Isolation where a customer or regulation requires it | The code has to support both, and moving a customer between them |
The guidance also makes a commercial point that matters to anyone pricing a product. Choosing a tenancy model, Microsoft says, is not only a technical decision but a commercial one, and a dedicated deployment can be offered as a higher-priced plan that recovers its cost. Decide which customers will need isolation before the architecture is chosen, not after the first enterprise deal asks for it.
The parts buyers forget to price
Most SaaS briefs describe the workflow customers will pay for. The parts below are rarely in the brief and always in the product. Each is a decision that moves the quote.
| Part | What to decide | Why it moves the number |
|---|---|---|
| Billing and plans | Trials, plan limits, upgrades, usage charges and what happens when a payment fails | Billing touches every account every month, and its edge cases are where the work hides |
| Identity | Email login only, or single sign-on for enterprise customers, now or later | Adding single sign-on later is cheaper if user records were designed for it |
| Roles inside an account | Who can do what, and whether customers define their own roles | Every feature has to respect permissions, so they add work everywhere |
| Support access | How your team looks inside a customer’s account, and how that is logged | Unsafe support access is a security finding waiting to happen |
| Data export and deletion | How a customer takes their data with them, and how it is deleted | The best buyers ask before they sign |
| Security review | Which assurance customers will ask for, such as a SOC 2 report | Controls, logging and evidence have to be built and run, not written later |
| Observability | The errors, performance and usage data you need to support customers | Without it, support means guessing |
On the security review: a SOC 2 report is an examination, by an independent auditor, of a service organisation’s controls relevant to security, availability, processing integrity, confidentiality or privacy, under criteria set by the AICPA. Whether your customers will ask for one depends on who they are. If they will, the product needs the controls and the evidence from the start.
The build is the smaller part of the cost
A SaaS product is paid for every month it runs: hosting, monitoring, security patching, upgrades, support and the next features. The build sets the shape of all of them. Microsoft’s guidance warns that a single shared deployment has limits, and that the costs of scaling it might increase nonlinearly, for example when a shared database runs out of throughput.
So ask every vendor what running the product will involve, not only what building it costs. A quote that is lower because it skipped the tenancy work, the observability or the automated deployment is usually a quote for higher running costs.
The decisions that set a SaaS development quote
Make these decisions before you ask for quotes, or ask every vendor how they assumed each one. Two quotes that assumed differently are pricing two different products. The SaaS development page sets out how we settle them before the first sprint.
The tenancy model
Shared, separate or mixed, and which customers will need their own deployment.
Billing
Plans, trials, limits, usage charges and failed payments, on a payment account in your name.
Identity
Whether enterprise single sign-on is in the first version or designed for later.
Roles and support access
Who can do what inside an account, and how your team gets in safely.
The assurance customers will ask for
A security questionnaire, a SOC 2 report or a sector standard, and when.
Where data lives
The regions customer data must stay in, for the buyers who ask.
Export and deletion
How a customer leaves with their data, and how it is removed.
Who runs it after launch
Hosting, monitoring, upgrades and support, and which of them the quote includes.
Is your SaaS brief ready to quote?
Tick what your brief decides today. Each unticked line is one that vendors will assume differently.
How to spend less without paying later
The ways to reduce SaaS development cost that hold up are about scope, not rate:
- Prove demand first. An MVP built on the right tenancy and billing model answers whether customers will pay without building the full product, and does not need replacing if the answer is yes.
- Defer, do not skip. Single sign-on, custom roles and usage billing can come later if the data model is designed for them now.
- Design the first session before you build it. The path from sign-up to the moment the product is worth paying for decides how many trials convert, and it is far cheaper to change in a prototype. See SaaS product design.
- Check whether you need to build. If a white-label platform covers most of the product, or the new product is really an extension of one you already run, those are cheaper routes. The build vs buy guide covers where that line usually falls.
The one saving that rarely holds is choosing the quote that left out the parts above. They are still needed. They arrive as change requests instead.
Why we do not publish a price
Many pages on this question publish ranges by product size. A range without the tenancy model, billing and identity decisions behind it describes someone else’s product, and anchors the reader on a number that has nothing to do with theirs.
What we do instead is make those decisions with you first, then price the product they describe, including what it will take to run.
Questions about SaaS development cost
How much does it cost to build a SaaS product?
It depends on the scope and on a handful of decisions more than on the number of screens: the tenancy model, billing, identity and single sign-on, roles, support access, the assurance customers will ask for, and who runs the product after launch. Make those decisions first and quotes become comparable.
What is the biggest cost driver in SaaS development?
Usually the parts a demo does not show: keeping customers’ data apart, billing, and identity. The tenancy model matters most over time, because it also sets the cost of running the product every month.
Is multi-tenant architecture cheaper?
Cheaper to run, in most cases. Microsoft’s architecture guidance notes that shared infrastructure is less expensive than dedicated resources for each tenant. It brings its own risks, such as one heavy customer slowing the others and one fault affecting everyone, and many products mix shared and dedicated parts.
What does a SaaS product cost to run after launch?
Hosting, monitoring, security patching, upgrades, support and new features, every month. How much depends heavily on the tenancy model and on how much of the operation is automated, so ask every vendor what running the product involves, not only what building it costs.
Should I build an MVP before the full SaaS product?
Usually, if demand is not yet proven. Build it on the tenancy and billing model the full product will need, so that it can grow rather than be replaced if customers pay. See MVP development.
Do I need SOC 2 for a SaaS product?
Only if your customers will ask for it, which is common when selling to larger companies. If they will, build the controls and the logging the audit needs from the start, because adding them later costs more.
Method and sources
The architecture guidance below we read at source in October 2026, and it is quoted or closely paraphrased in the text. The keyword volume behind the topic comes from a Semrush pull for the US on 5 October 2026. The list of parts buyers forget and the decisions that set a quote are our judgement from scoping and building SaaS products, written as judgement rather than as data. We publish no prices or ranges.
- Tenancy models for a multitenant solutionMicrosoft, Azure Architecture Center. Tenancy as a commercial decision, the cost of dedicated deployments per tenant, the risks of shared infrastructure, mixed models, and nonlinear scaling costs
- Silo, pool, and bridge modelsAmazon Web Services, SaaS Lens of the Well-Architected Framework. Definitions of the silo, pool and bridge models, and the regulatory, noisy neighbour and cost reasons for choosing between them
- System and Organization Controls: SOC Suite of ServicesAICPA and CIMA. SOC 2 examinations of controls relevant to security, availability, processing integrity, confidentiality or privacy
