SHIFT >_CODE
← Journal

SaaS architecture basics: tenants, roles and billing

A SaaS product serves many companies from one system. Three early decisions - how customer data is separated, how access is managed and how payments work - shape everything that follows.

Software as a service means that many customers use the same product, each with their own data, users and settings. Some decisions made in the first weeks are hard to change later, so it is worth understanding them even if you are not a developer.

Separating customers’ data

Every company using the product - a "tenant" - must see only its own data. There are several ways to achieve this: a shared database where every record belongs to a tenant, separate schemas, or even a separate database or server for each customer. Shared storage is simpler and cheaper to run; stronger isolation is easier to explain to clients with strict security requirements. Whatever the choice, separation must be enforced at the data level, not only in the interface.

Roles and permissions

Inside each customer there are different people: owners, managers, regular employees, sometimes external partners. Define a small set of roles from the start and check permissions on the server for every action. Adding a new role later is easy; fixing a system where anyone could do anything is painful.

Subscriptions and billing

Decide early how customers pay: monthly or yearly plans, payment per user, limits on usage, a free trial. Plans determine which features are available, so the product must know what each customer has paid for. Use an established payment provider, store only references to payments rather than card data, and handle failed payments, upgrades and cancellations gracefully.

Onboarding and settings

A new customer should be able to start without your help: create an account, invite colleagues, make basic settings. Each manual step you perform for a client is a cost that grows with every new customer.

Preparing for growth

You do not need to build for millions of users on day one, but you should be able to grow without rewriting everything. Keep the code organised into clear modules, log important events, automate deployments and backups, and monitor performance. Those habits make scaling a gradual process instead of an emergency.

The short version

Separate customer data reliably, define roles and check permissions on the server, design plans and billing early, make onboarding self-service and keep the system ready to grow. These foundations decide how easily the product can develop later.