If you're building software for more than one customer, one of the first architecture decisions is whether it should be single-tenant or multi-tenant. Here's what that means without the jargon.
Single-tenant: one copy per customer
Each customer gets their own copy of the application, often with their own database and server.
- Pros: strong isolation, easy per-customer customisation
- Cons: every new customer means another deployment to run, update and monitor
Multi-tenant: one platform, many customers
All customers share the same application and infrastructure, with their data securely separated.
- Pros: one codebase and deployment, new customers onboard in minutes, updates reach everyone at once
- Cons: isolation must be designed carefully from the data layer up
Which should you choose?
Most SaaS products should be multi-tenant. It's what makes onboarding cheap and updates simple. Single-tenant makes sense for some enterprise or regulated customers who require dedicated infrastructure.
Turning a single-client tool into a SaaS product
A common story: you built a tool for one client, it works, and now others want it. A multi-tenant transformation usually involves:
- Adding tenant isolation to the data model
- Migrating the original client safely
- Organisation onboarding and per-tenant settings
- Role-based access control for each organisation
- Billing and subscription management
We've done exactly this, for example turning a student advising tool into a multi-tenant SaaS. If you're facing the same decision, our enterprise software and web development teams can help.