One product. Separate business accounts.
If several companies sign up for your software, each expects its people, settings and records to stay its own. That boundary has to hold on every screen, report, export and integration.
Picture a software product for clinics. Each clinic signs up, invites its doctors and front-desk staff, sets its own working hours and branding, and stores its own patient records. There is one login page, one codebase and one set of servers. Yet clinic A must never see clinic B's records, whether through a search, a report, a shared link or a mistyped address. That's a multi-tenant platform; in plain terms, each customer organisation is a tenant.
The boundary is easy to describe and easy to get wrong. It has to be part of how every record is stored and fetched, rather than a filter added to some screens. That's why we plan the organisation model before building the account experience, and test it as deliberately as any feature.
How separate is separate?
There's more than one way to keep tenants apart. The right one depends on your customers and what they'll ask of you.
Shared database, strict boundaries
All organisations live in one database, with every record tagged to its owner and every query restricted to it. Efficient to run and update, and suitable for most business products.
A database per organisation
Each tenant's data sits in its own database. Costs more to operate, but some larger or regulated customers ask for it in their contracts.
Shared by default, separate on request
Most tenants share while specific customers get their own database. Workable, though worth planning from the start instead of retrofitting.
Cases the design has to answer.
A consultant in two clients
They belong to two customer organisations with different roles. Switching between them must not carry the first one's permissions into the second.
Your own support staff
They need a wider view to help customers, but that access should be limited and recorded instead of open by default.
A customer leaves
Decide what happens to their data: export, a retention period, then deletion. Their users lose access without affecting anyone else.
Two organisations, one record
Can tenants share a document or transfer ownership? If so, define it explicitly. It's hard to add safely once the boundary has gone fuzzy.
Set per organisation.
- Users, invitations and roles inside each account.
- Plan, limits and billing tied to the organisation, as on subscription platforms.
- Settings such as working hours, tax details, templates and branding.
- Reports covering one organisation's records and nothing else.
Settle before the first customer signs up.
These are cheap to decide on paper and expensive to change once real organisations are using the product.
- What counts as an organisation: a company, a branch, a franchise outlet, or a team inside a larger firm.
- Who creates a new organisation: the customer through sign-up, or your team after a sales conversation.
- Which settings each organisation controls, and which stay fixed across the platform.
- What your own staff can see inside a customer account, and how that access is logged.
- Whether organisations can sit under a parent, such as a group with several companies.
- What a departing customer can export, and how long their data is kept afterwards.
Multi-tenancy questions.
Can a person belong to several organisations?
Yes. One login, separate memberships, separate permissions in each, and a clear indicator of which organisation they're working in right now.
Can each organisation have its own plan?
Yes. Plan rules and billing attach to the organisation account, so one customer can be on a larger plan with more users while another stays on a starter tier.
Can we turn our single-customer software into a multi-tenant product?
It's possible, but it touches how almost every record is stored and queried. We'd start with a technical review and plan the change in stages so current users aren't disrupted.
Selling one product to many businesses?
Tell us who your customers are and we'll talk through where their boundaries should sit.