Notes for owners · MVP and Product Development
Multi-Tenant SaaS vs a Separate Copy for Each Customer
Multi-tenancy suits a product sold to many customers on subscription, while separate copies suit a few large accounts on negotiated contracts. Copies work while there are two or three customers. Beyond that, every fix is repeated per server and the copies drift apart. GullySystem decides the tenant boundary before features are built on it.
Ganesh HS, Strategy and Technology, GullySystem · · 3 min read
What each model means day to day
With separate copies, each customer runs its own installation. It has its own server, its own database and often its own small changes. Setting up a new customer means setting up a new environment.
With multi-tenancy, one running system serves every customer. Each customer’s records sit inside it, marked as belonging to that account. A new customer is a new account, not a new server.
Where separate copies start to cost
The cost does not show at first. Two or three copies with one person looking after them feel manageable.
It grows with each customer. A fix has to be applied server by server, and some copies get missed. Over time the same button behaves differently at two customers. Finding out why means opening both.
- Every fix repeated and verified per copy
- Copies drifting onto different versions
- A new server needed for each new customer
- Running cost rising in step with customer count
What multi-tenancy asks for in return
Sharing one system means isolation must be enforced, not hoped for. Every record, file, report, export, background job and API call needs an account context. Enforcing it in the data layer means no single screen has to remember.
It also has to be tested. Before launch, someone logs in as one account and tries to reach another through screens, direct links, exports and the API.
One heavy customer can slow the rest. Queues, caching and limits per account keep that in check.
- Shared schema with scoping enforced on every query
- A separate schema for each tenant
- A separate database for larger accounts
When a dedicated instance still makes sense
A handful of large customers on negotiated contracts can justify their own instance. They may ask for it in a security questionnaire, or carry volumes that call for it.
This does not have to mean a separate codebase. A shared platform can still give its largest accounts a database of their own. Everyone stays on the same release.
Moving existing copies onto one platform
Move customers one at a time, not all at once. Run a trial migration for each and let that customer check it against its own records. Retire the old copy only after they agree.
Customer-specific changes need a new home before the move. A special approval or invoice format becomes configuration or a feature switch on that account. No customer keeps a private branch of the code.
- List what differs between each copy first
- Turn each difference into a setting or a switch
- Migrate one customer and have them verify
- Retire the old server only after sign-off
Copy drift register
A table with one column per customer copy and one row per difference you know about: version, custom fields, invoice formats, approvals and reports. Mark which differences can become plan settings. The rows that cannot are the real migration work.
Open a blank worksheet to printQuestions owners ask
Is data on a shared platform less safe than on a separate copy?
It depends on how isolation is enforced. Scoping every read to an account and testing cross-account access before launch is what keeps data apart. A separate database adds physical separation for buyers who ask.
Can we add multi-tenancy after customers are live?
Yes, but it is substantial rework. Every table, file, report and job has to be given an account. Deciding the boundary first is less disruptive.
Does one platform mean every customer gets the same features?
No. Plans and feature switches decide what each account sees. A customer with negotiated terms gets an override on its account, while the code stays the same for all.