Short answer
SaaS application development services are judged on three decisions taken before any feature work: how tenants are isolated from each other, how their records are authorised at the object level, and how usage is metered. Each is expensive to retrofit, and none of them shows up in a demo.
Key takeaways
- 01AWS describes three tenant isolation models, and they have opposite cost and agility profiles.
- 02Broken object level authorization is OWASP's top API risk, rated easy to exploit and widespread.
- 03In a pooled architecture, one tenant's outage is likely to be every tenant's outage.
- 04Usage metering is a separate system from invoicing, not a field on a subscription.
Tenancy is the architecture, not a setting
AWS's tenant isolation whitepaper names three models, and a product effectively picks one. Silo gives each tenant a fully separate stack. Pool shares infrastructure across all of them. Bridge applies whichever fits per service. They are not interchangeable settings — they produce different cost curves, different onboarding work and different failure behaviour, which is why the question belongs in the first week of a software development engagement rather than the first release.
| Silo | Pool | |
|---|---|---|
| Infrastructure | One stack per tenant | Shared across tenants |
| Cost profile | Idle capacity per tenant | Scales with actual load |
| Outage blast radius | Usually one tenant | Likely every tenant |
| Onboarding a customer | Provision new infrastructure | Create a record |
Where multi-tenant data actually leaks
AWS is direct about the pooled case: sharing resources increases the chance of cross-tenant access, and that is a reason for more diligence rather than less. The specific failure has a name. OWASP ranks broken object level authorization first in its 2023 API Security Top 10, rating it easy to exploit, easy to detect and widespread. An attacker changes an identifier in a request; in a multi-tenant product, what comes back belongs to another company.
- Authorise against user policy and hierarchy, not against the shape of the request
- Check permission in every function that uses client input to reach a record
- Prefer random, unpredictable GUIDs to sequential record identifiers
- Write tests for the authorisation mechanism and block deploys that fail them
Metering is a subsystem, not a price field
Usage-based pricing needs a stream of events, not a number attached to a plan. Stripe's own documentation makes the distinction plain: its Billing Meters integration reconciles usage at invoice time, and teams that need real-time usage visibility, prepaid credits or enterprise commitments are pointed at a different platform entirely. That is the shape of the problem — showing a customer what they have consumed mid-month is a separate system from charging them for it at the end.
Onboarding is what the second year costs
AWS puts onboarding automation and decentralised management in the silo model's cost column: every new tenant means new infrastructure, and monitoring has to be aggregated back from a scattered footprint. Twenty siloed tenants are manageable; a thousand, AWS notes, begins to undermine operational efficiency. Pooling inverts the problem — one view of every tenant, at the price of a shared blast radius and harder per-tenant cost attribution.
Neither is wrong. What is wrong is discovering which one you built after a regulated customer asks for a dedicated environment. Work through it against real accounts you expect to sign, not an abstract scale target.
What to ask before signing
- Which isolation model, and which specific customer requirement drove it
- How object-level authorisation is tested, and what happens when a test fails
- How long onboarding takes from signed contract to first login, and how much is manual
- What a tenant sees about their own usage before the invoice arrives
Answers to those four say more than any architecture diagram. See how we build web applications, or look at our portfolio and talk to us about where your product sits.
Frequently asked questions
In principle, and it is the usual plan. In practice the move requires per-tenant provisioning, deployment and monitoring that a pooled product never needed, so budget it as a project rather than a configuration change.
No. AWS treats fully siloed stacks as a valid SaaS variant as long as identity, onboarding, metering, deployment and operations are shared around them. What makes it SaaS is the unified operational layer, not shared servers.
Write authorisation tests that use a second tenant's identifiers against the first tenant's session, for every endpoint that accepts an object ID. OWASP's guidance is that these tests should block deployment when they fail.
No, but decide early whether events will be recorded. Emitting usage events costs little while you are still charging a flat fee, and it means switching to usage-based pricing later is a pricing decision rather than an instrumentation project.
Who your first ten customers are and what their compliance teams will require. That answer determines the isolation model, and the isolation model determines most of the rest of the build.
Sources
Keep reading
What a SaaS Web Design Agency Has to Get Right
A SaaS marketing site and the product it sells are different problems. Building the first one like the second is the most common and most expensive mistake.
Enterprise Application Development: What Actually Decides the Outcome
The framework your vendor prefers is close to irrelevant. Integration surface, access control and who answers the pager decide whether an enterprise application lasts.
Financial Services Website Development: Three Deadlines That Already Passed
Three compliance dates passed between March 2025 and June 2025, and all three land on the public website rather than on the core banking system behind it.
Stop thinking about it.
Start building.
Talk with us — free consultation, no commitments.