SaaS development for a product that has to serve its tenth customer as well as its first.
We build the multi-tenancy, access and release decisions in early, because they are the ones that decide what every later customer costs to onboard.
- Made deliberately
- Made by default
Made early, usually implicitly
- Data separation
- Configuration
- Release
- Isolation of noisy tenants
Illustrative shape, not a measured figure. No cost curve from an engagement is published.
Three ways a working SaaS product becomes expensive to grow.
SaaS is the wrong frame for software with one customer, however large. It is also premature before the product has been validated.
Every customer needs a code change
Configurability was deferred, so each sale now costs engineering time and the margin falls as you grow.
One customer's data reaches another
Or the fear of it does, which stops enterprise deals at security review whether or not it has ever happened.
Releases stop being routine
More customers means more risk per release, so shipping slows exactly when the roadmap needs it to speed up.
What we take on.
Where the product is still finding its shape, a first version matters more than any of this.
Multi-tenant architecture
Separation of customer data and configuration, decided deliberately rather than inherited from whatever the first customer needed.
Tenant configuration
So a new customer is a setting rather than an engineering ticket, which is the decision that sets your margin.
Access and roles
Permission models that survive a security review, designed before the interface rather than retrofitted into it.
Subscription and billing integration
Plans, usage and lifecycle connected to a billing provider rather than modelled from scratch.
Release and deployment
Shipping to many customers at once, with staged rollout and a tested way back.
Scale and performance work
Where the product works and the growth curve is now the constraint.
Where it is a single-customer system, the multi-tenant work is cost without return.
Four multi-tenancy decisions, and what each one costs you later.
These four are made early, usually implicitly, and they determine what a new customer costs to onboard for the life of the product.
Data separation
The lighter option
Shared tables with a tenant column
The heavier option
A database or schema per tenant
What it decides
Cost per tenant against how easily you can answer a security review
Configuration
The lighter option
Settings in the product
The heavier option
Code branches per customer
What it decides
Whether sales can close without engineering, which is the margin question
Release
The lighter option
One version, everyone upgrades together
The heavier option
Customers choose when to upgrade
What it decides
Whether you support one codebase or several, permanently
Isolation of noisy tenants
The lighter option
Shared capacity
The heavier option
Limits and quotas per tenant
What it decides
Whether your largest customer can degrade the service for everyone else
None of these has a universally right answer, and the lighter option is often correct early. Trouble comes from choosing by default and discovering it later.
How a SaaS engagement runs.
Establish where you are on the four decisions
Including the ones made implicitly, because most products have made all four without recording any.
Fix the one that is costing you now
Usually configuration, because it is the one that shows up in every sales conversation.
Model access and roles before the interface
Retrofitting permissions into a finished product is among the most expensive corrections there is.
Make release routine at your current tenant count
Before growth makes each release riskier rather than after.
Instrument per tenant
Usage, cost and performance by customer, because the aggregate hides the customer who is about to churn or bankrupt you.
Hand the release process to your team
So shipping does not depend on us being available.
Closest published platform evidence, not equivalent.
Vizitor is a workplace operations platform with 500+ workplaces using it. Its published scale is relevant context for a SaaS buyer, but it is not an approved multi-tenant SaaS development case study.
- Workplaces running the platform. Published current scale for the platform. It does not establish its tenancy architecture.
- 500+Workplaces running the platform. Published current scale for the platform. It does not establish its tenancy architecture.
- Countries served. Which brings the data residency and access questions this page is about.
- 15+Countries served. Which brings the data residency and access questions this page is about.
- VizitorWorkplace operations. A production platform used across many workplaces. Closest published platform context, not equivalent to a SaaS development case study.Read the case study
- FiteloConsumer health. A production system serving a large user base, with evaluation and cost controls around it.Read the case study
The Vizitor figures are published on that product's own site and describe its current scale. They are platform context, not a projection for yours.
See all case studiesWhere SaaS engagements usually start.
Documented relevance: workplace operations, through the Vizitor platform. Other sectors are not claimed here.
A product closing enterprise deals for the first time
Where security review is now asking questions the architecture cannot answer.
A margin that falls as you grow
Where each new customer takes engineering time nobody costed.
A release cadence that slowed
Where more customers made every deployment riskier.
A single-tenant product being sold to a second customer
Which is the moment the four decisions stop being theoretical.
What multi-tenancy costs to run, which the search results do not discuss.
Several ranking results publish build cost ranges. None discusses what the architecture costs to operate afterwards, which is the same buyer anxiety answered more usefully.
Idle capacity per tenant
Heavier isolation means capacity reserved whether or not a customer is using it. That is a monthly cost set by an early decision.
Support surface grows with variation
Every per-customer difference is a supported path. Configuration is cheaper to support than code branches.
Upgrades cost per version, not per customer
Letting customers choose when to upgrade means maintaining several versions at once, indefinitely.
Per-tenant instrumentation is not optional
Without it, an unprofitable customer is invisible until the aggregate bill moves.
We do not publish figures, because they depend entirely on your tenant profile. We do model these four before the architecture is settled.
What a security review will ask, and where the answer comes from.
We do not claim a certification we have not been audited against. What we do is make sure these five have written answers before your first enterprise review rather than during it.
How is our data separated from other customers
The data separation decision, which is why it is made deliberately rather than inherited.
Who at your company can see it
The access model, plus how internal access is granted and removed.
Where is it stored
The hosting and residency decision, agreed before build rather than during review.
What happens when we leave
Export and deletion, designed as a feature rather than handled as a request.
What do you log
The audit record, and who can read it, since logs are customer data too.
What you have as the engagement runs.
Framed as ongoing rather than as a handover date, because a SaaS product does not have one.
The four decisions, written down
Where your product currently sits on each, with the reasoning, so a later reversal is deliberate rather than accidental.
Per-tenant instrumentation
Usage, cost and performance by customer, reporting into whatever your team already reads.
The five security-review answers
Written before your first enterprise review rather than assembled during one.
A release process your team runs
Staged rollout and a tested way back, exercised by your engineers rather than by us.
A written list of deferred scope
What was not changed and why, so the next decision starts from the record rather than from memory.
What teams ask before they start.
Pick a topic, or ask us directly. We answer every inbound within one business day.
Still have questions?
Talk to a senior engineer, not a bot.
Tell us what happens when your next customer signs.
If the answer involves engineering time, configuration is already costing you margin. Describe your product and customer count and we will name the decision worth changing first.