One architectural decision determines most of what a SaaS product will cost to build and nearly all of what it will cost to run. Whether you are multi-tenant or single-tenant is that decision, and it is very expensive to reverse after launch. Most pages selling SaaS development will not raise it with you until you are already committed.
One app, one database, a tenant key. The SaaS economic model, and the isolation work is real engineering.
An isolated instance each. You are running a hosting business, and versions drift apart.
One missing filter shows a customer another customer’s data. Enforce isolation at the database.
Multi-tenant or single-tenant, and why it decides your economics
| Multi-tenant | Single-tenant | |
|---|---|---|
| How it works | All customers share one application and one database, separated by a tenant key | Each customer gets their own isolated instance |
| Cost per customer | Falls as you grow. This is the SaaS economic model | Roughly flat. You are running a hosting business |
| Releasing | Once, for everybody | Per instance, and versions drift apart |
| The hard part | Tenant isolation. One missing filter leaks another customer’s data | Operational load, which grows linearly with your customer count |
| Right when | Many customers with broadly the same needs | Few large customers with hard data-residency or customisation demands |
Multi-tenant is the default for a reason, but the isolation work is real engineering rather than a configuration setting. Every query, every background job and every export has to be tenant-aware. Enforce it at the database level, not by remembering to add a filter in application code, because the failure mode is showing one customer another customer’s data and there is no recovering from that commercially.
What SaaS development actually involves beyond the application
- Subscription billing. Plans, trials, upgrades, downgrades, proration, failed payments and dunning. Reliably underestimated, and it touches everything.
- Onboarding and provisioning. A new tenant has to be created, seeded and usable without an engineer being involved.
- Roles and permissions. Customers will ask for their own admin, their own users, and eventually their own custom roles.
- Usage metering. If you charge by seats, calls or storage, you need to count it accurately enough to invoice on and defend.
- Tenant-aware operations. Backups, restores, exports and deletions all have to work for one customer without touching the others. A restore that rolls back every tenant is not a restore.
- Compliance. Enterprise buyers will ask for SOC 2 and a data processing agreement. Building with that in mind is far cheaper than retrofitting it during a deal.
Is SaaS being replaced by AI?
Google lists this question on this search, so it is worth a direct answer. No, but the buyer’s expectation of what software should do has moved, and products that are only a database with forms on top now look thin against that expectation.
What has actually changed is that a feature which used to be a differentiator, such as search, summarising or classification, is now table stakes and cheap to add. The durable moat has moved to the places it always was for good software: proprietary data, workflow depth, integrations, and being the system of record. If your SaaS is defensible only because it has a chat box, that was never the moat.
What drives the cost of building a SaaS product
- Number of tenant-aware surfaces. Not features. Every place data crosses a boundary is where the isolation work lands.
- Billing complexity. Flat per-seat pricing is straightforward. Usage-based tiers with overages and annual commitments are a product in themselves.
- Integrations. Each one carries its own authentication, rate limits and failure behaviour, and each becomes a support obligation.
- Compliance posture. Audit trails, retention rules and access controls are cheap to design in and expensive to add later.
- Scale assumptions. Building for a hundred tenants and building for ten thousand are different systems. Be honest about which you are.
For concrete figures on a first release, see what an MVP costs. On the company-structure question that Google also surfaces here, that is a matter for an attorney and an accountant in your state rather than for your development partner, and any vendor answering it confidently should worry you.
What to ask a SaaS development company
- How is tenant isolation enforced? The answer should mention the database, not developer discipline.
- Can you restore one tenant to a point in time? Ask whether they have ever actually done it.
- Who owns the billing logic? If it lives entirely inside a payment provider’s dashboard, changing pricing later will be painful.
- What does adding a new plan involve? If it needs an engineer, your pricing will ossify.
- What happens at ten times the load? Not a promise. Which component gives first, and what it costs to fix.
Building SaaS with Sthenos
We build multi-tenant products for organisations across Maryland and the Washington DC area, delivered through an established engineering partnership with NeoSOFT. The architecture conversation happens before the estimate rather than after it, because that is the decision that moves both numbers. If you are weighing multi-tenant against single-tenant, or retrofitting isolation into something already live, talk to our engineers. Related: the production readiness checklist we run before a system takes real users.