SaaS Development Services

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.

Multi-tenant or single-tenant, and why it decides your economics

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.

The tenancy models in detail, and the vocabulary that goes with them

Multi-tenant is not one architecture. It is a range of isolation choices, and the words below are the ones your engineers, your auditors and your first enterprise buyer will all use. The model should be picked against your compliance obligations and your expected tenant count before the estimate, and the reasoning written down, because it is the decision every later argument refers back to. There is a longer treatment in our own guide to multi-tenancy in cloud architecture, and a shorter one in multi-tenancy explained.

Shared database with a tenant identifier

One schema, one set of tables, and every row carries the tenant it belongs to. This is the cheapest model to run and to release, because there is exactly one copy of the application and one copy of the schema. The cost is that isolation now lives inside your code and your database rules. Every query, every background job, every export and every scheduled report has to carry the tenant filter, and the one that forgets is a data leak rather than a bug.

Schema per tenant

One database, one schema per customer, the same tables inside each. Isolation becomes much easier to reason about, and a single customer can be exported, archived or dropped cleanly without touching anybody else. You pay for it at migration time: a schema change now runs once per tenant and has to succeed on all of them, and connection limits and catalogue size start to matter as the tenant count climbs.

Database per tenant

Each customer gets their own database, and sometimes their own instance. This is usually what a regulated buyer means when they ask for isolation, and it makes per-tenant backup, restore, encryption keys and residency straightforward rather than clever. The cost is operational. Provisioning, patching, monitoring, upgrading and migrating are now a fleet exercise, and the fleet grows every time you sign a customer.

Noisy neighbour and resource contention

In any shared model, one tenant can consume capacity that everybody else needed. A single customer bulk importing ten million rows, or running an unbounded report, degrades the product for tenants who did nothing wrong. The defences are engineering ones: per-tenant rate limits and quotas, work queued rather than run inline, expensive reporting moved off the transactional database, and limits that are set deliberately rather than discovered during an incident.

Tenant-aware backups and restore

A backup that can only be restored as a whole is not much use to a SaaS product, because the event you actually face is one customer destroying their own data. Restoring the platform to roll back one tenant means rolling back everyone else too. Whichever isolation model you choose has to answer the question of how a single tenant is restored to a point in time, and the answer needs to have been rehearsed rather than assumed.

Per-tenant configuration

Customers will ask for their own branding, their own terminology, their own workflow states, their own required fields and eventually their own business rules. Configuration that is data is cheap and stays cheap. Configuration that becomes a branch in the code is how a multi-tenant product quietly turns into several single-tenant products sharing a repository, and it is the most common way the economics of SaaS are lost.

Data residency

Some buyers cannot let their data leave a jurisdiction, and that constraint reaches further than the primary database. Backups, logs, search indexes, analytics, caches and any third party you send data to are all in scope. Residency is one of the few requirements that can force a database per tenant or a separate regional deployment, which is why it belongs in the architecture conversation rather than in a later security review.

Tenant onboarding and offboarding

Creating a tenant should be a routine, automated operation: the tenant record, its first administrator, seed data, an isolated place for its files and whatever third-party accounts it needs. Offboarding matters just as much and gets built last. A customer who leaves is entitled to an export they can actually use, and a deletion that reaches every store that holds their data, including logs, caches and analytics.

Usage metering and billing per tenant

If you charge by seats, calls, storage or events, the number on the invoice has to be defensible when a customer disputes it. That means recording usage as immutable events per tenant rather than reading a live counter, keeping the record long enough to answer a query about a past period, and being able to show a customer the same figure you billed them from.

SSO and SCIM provisioning

The first large customer will ask to sign in with their own identity provider, and the one after that will ask you to create and deactivate their users automatically. Single sign-on and SCIM provisioning are per-tenant settings, not a global switch: each tenant has its own identity provider, its own domain, and its own rule for what happens to a user who is removed upstream.

Tenant-scoped roles and permissions

Role-based access control in a SaaS product has two layers that are easy to confuse. There are your own staff, who can reach across tenants for support and must be logged when they do, and there are the customer’s own users, whose roles apply only inside their tenant. Getting the second layer wrong is an inconvenience. Getting the first layer wrong is the incident you tell customers about.

What SaaS development actually involves beyond the application

Everything around the application, once it has real customers

The list above is the product. This one is the operational surface a SaaS product acquires the day somebody pays for it, and it is the part most estimates leave out. These belong on the build list with the same standing as features, because they are the ones a renewal conversation turns on.

• Usage telemetry. Which tenants use which features, how often, and where they abandon. A product you cannot measure per tenant leaves you guessing about churn, and it leaves your own pricing unanchored.
• Audit logs. Who saw or changed which record, when, and from where, per tenant, and readable by the customer rather than only by you. Enterprise buyers ask for this early and it is far cheaper designed in than reconstructed later.
• Observability. Logs, metrics and traces that carry the tenant identifier, so a support ticket that names one customer can be answered without reading everybody’s traffic. Untagged telemetry is the reason a multi-tenant incident takes hours to attribute.
• Backups and disaster recovery. A schedule is not the deliverable. A restore performed into a clean environment and checked against production is the deliverable, along with an agreed recovery point and recovery time that the architecture can actually hold.
• Incident communication. When the product is down for everybody, customers need somewhere to look that is not your support inbox, and a written note afterwards that says what happened and what changed. Decide who writes it and where it goes before you need it.
• Release process. In a shared model you release once for everybody, which is the advantage and the risk. Automated, repeatable deployment, a rehearsed rollback, and migrations that can run while the product is serving traffic are what make that advantage safe to use.
• Environments and test data. A staging environment with realistic, non-production tenant data is what lets you test an isolation change at all. Testing tenant separation against three rows proves nothing.

Our production readiness checklist scores most of this in public: seven areas, twenty nine checks, each scored zero, two or four against the evidence a reviewer would accept rather than against an opinion.

The stack and the patterns a SaaS product runs on

Every platform and service named here is one Sthenos already publishes elsewhere on this site, and each entry links to the page that carries it. We do not list a logo we cannot point at.

• Clouds. AWS, Microsoft Azure and Google Cloud. For a SaaS product the choice usually follows your buyers rather than your engineers: a customer with an existing commitment on one cloud, or a residency rule, decides it faster than any technical comparison will.
• Containers and orchestration. Containers and Kubernetes, as Azure Kubernetes Service and Google Kubernetes Engine on those two clouds. Containers are what make one build artefact run identically in every environment, which is the precondition for releasing once for every tenant.
• Infrastructure as code. Terraform, Ansible and CloudFormation, named on our DevOps engineering page. In a SaaS product this stops being a tidiness argument the first time you have to stand up a second region or an isolated deployment for one customer.
• Databases. Postgres, MySQL, SQL Server and MongoDB all appear in work we publish. Whichever you use, the tenant boundary belongs in the database, enforced by rules the application cannot forget, rather than in a filter a developer has to remember.
• Search. A separate search index is a second copy of your data, so it inherits every tenancy question the primary store has: the tenant filter, the residency rule, and the deletion that has to reach it.
• Content delivery and edge. Static assets, uploads and downloads served from an edge network rather than from your application servers. Our AWS page carries this as content delivery and edge workloads.
• Background jobs and queues. Anything slow, bulk or scheduled belongs off the request path. Our readiness checklist scores a health check on whether it touches the database, the queue and the downstream APIs, rather than reporting success whenever the process is running.
• CI/CD and release automation. Automated pipelines, named across our cloud and DevOps pages. A shared product is released for everybody at once, so the pipeline and the rollback are part of the isolation story, not separate from it.
• Autoscaling. Capacity that follows demand, with limits and cost ceilings set deliberately, so a traffic spike or one tenant’s bulk job cannot become an unbounded invoice.

The patterns. Microservices where a service boundary earns its operational cost and not before, API-first so the product your customers integrate with is the same product your own interface uses, and event-driven processing where work has to keep flowing while a downstream system is unavailable. Sthenos already builds all three, and on a SaaS product each of them inherits the tenant boundary: a service, an API and an event all have to say which tenant they belong to.

What a SaaS engagement should hand you, and how the work runs

What lands on your side. These are the artefacts a SaaS engagement should hand you, and they are worth naming in the contract rather than assuming.

• The repository and the cloud accounts, in your name from the first commit, with no licence back to the vendor and no dependency on any one supplier continuing to exist.
• A written tenancy decision. Which isolation model, what it was chosen against, what it makes expensive later, and what would have to be true to change it.
• Working software at the end of every sprint, in an environment you can open, rather than a demonstration at the end.
• A production readiness review scored against a published checklist such as ours, with the failing checks listed as work rather than as opinions.
• The compliance evidence trail. Access control, audit logging, encryption, retention and deletion, documented as the artefacts your own auditor asks for.
• Operational handover. How a tenant is created, how one is restored, what the alerts mean and who is expected to answer them.

How the work runs. Sthenos works in two week sprints, so working software arrives every two weeks, and a first production release typically lands in three to six months. The order below is deliberate: each step exists because doing it later is dramatically more expensive than doing it here.

1. Architecture and tenancy decisionThe isolation model, the residency constraints, the identity approach and the billing shape, settled and written down before an estimate is given.
2. The tenant boundary firstThe tenant record, the enforcement rules in the database, and the tests that prove one tenant cannot read another. This is the slice everything else is built on top of.
3. The product slice that proves the modelOne real workflow, end to end, for two tenants at once, so the boundary is exercised by real behaviour rather than by a unit test.
4. Billing and meteringPlans, trials, upgrades, proration and failed payments, wired to a real provider, with usage recorded per tenant as events you can defend.
5. Administration, roles and onboardingTenant creation without an engineer, customer-side administrators, roles inside a tenant, and staff access that is logged when it crosses a boundary.
6. Hardening and evidenceAccess control on every route, audit logging, encryption in transit and at rest, retention and deletion rules per data class, and the evidence trail assembled as it is built.
7. Production readiness review, then launchReliability, recovery, observability, security, capacity, rollback and ownership scored before real customers arrive, with the gaps closed or accepted in writing.

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 else moves the number, and how a SaaS build is priced

Three more drivers sit underneath the list above, and each of them is architectural rather than a matter of scope.

• The isolation model itself. A shared database with a tenant key is the cheapest to build and the most demanding to prove. A database per tenant is simpler to reason about and carries a permanent operational bill that grows with every customer you sign.
• Per-tenant customisation. Configuration held as data is cheap. The first customer-specific branch in the code is not, because it is never the last, and from then on every release has to be considered against each variant.
• Migration from an existing product. Retrofitting isolation into something already live is a different project from building it. The data has to be moved, the queries have to be rewritten, and it has to happen without downtime for customers who are already paying.

How Sthenos is engaged. Our rates are $150 to $250 per hour, depending on the seniority and mix of the team. The same work is contracted three ways, and the right one depends on how settled the scope genuinely is.

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.

Three more questions, about the operational side

• Show me a tenant restored to a point in time. Not the backup schedule. The rehearsal, and who ran it.
• How does a customer sign in with their own identity provider? Single sign-on and provisioning are per-tenant settings. If the answer is a global switch, the first enterprise buyer will find out.
• What happens to a customer’s data when they leave? An export they can use, and a deletion that reaches logs, caches, search indexes and analytics, not only the primary database.

Frequently asked questions

What is multi-tenant SaaS?

Multi-tenant SaaS means one running application serves many customer organisations, called tenants, with their data separated by the software rather than by giving each customer its own copy. It is what makes the cost of serving a customer fall as you add more of them.

What is the difference between single-tenant and multi-tenant?

A single-tenant product gives each customer an isolated instance, so cost per customer stays roughly flat and versions drift apart. Multi-tenant shares one application and one database behind a tenant boundary, so you release once for everybody and the isolation work becomes real engineering.

How do you isolate one tenant’s data from another’s?

At the database rather than by remembering to add a filter in application code. Depending on the model that means row level rules keyed on the tenant, a schema per tenant, or a database per tenant, plus background jobs, exports, search indexes and backups that are all tenant-aware.

How much does SaaS development cost?

Sthenos rates are $150 to $250 per hour depending on the seniority and mix of the team, and a SaaS build is priced from its architecture rather than from a template. The isolation model, billing complexity, integrations and your compliance posture move the number more than the feature list does.

How long does it take to build a SaaS product?

We work in two week sprints, so working software arrives every two weeks, and a first production release typically lands in three to six months. A SaaS product is rarely finished at launch: the release after it is where billing edge cases and the second tenant’s requirements land.

Can you migrate a single-tenant application to multi-tenant?

Yes, and it is the harder direction. Every table needs a tenant home, every query needs the boundary enforced, and existing customers have to be moved without downtime. Treat it as a project in its own right rather than a refactor done alongside feature work.

Do you build for SOC 2 readiness?

Yes, and we are explicit about our own posture. As of September 2026 Sthenos is not SOC 2 attested and holds no report of its own. We build to the controls an audit looks for, including access control, audit logging, encryption and retention, and hand you the evidence trail.

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.

More about SaaS development

Architecture. Multi-tenancy in cloud architecture, multi-tenancy explained, and what we build for independent software vendors.

Services. Custom software development, MVP development when the first release is the question, and cloud migration when the product already exists somewhere else.

Before launch. The production readiness checklist and the production readiness audit, plus penetration testing for the buyer who asks for a report before they sign.

Cost. What an MVP costs, and our rates and delivery terms on about Sthenos Technologies.

Ready to talk about tenancy? Bring the architecture question to the first call rather than the feature list, because it is the one that moves both the build number and the running cost. Talk to our engineers.