SaaS architecture worth committing to.

Choose a tenancy model deliberately

There are three common approaches and the decision is difficult to reverse.

Shared schema with a tenant column is simplest to operate and cheapest at scale. The risk is that one missing filter in one query leaks data between customers, so isolation must be enforced structurally - row-level security or a query layer that cannot omit the filter - rather than by developer discipline.

Schema per tenant gives stronger isolation and simpler per-customer export, at the cost of migrations that must run across every schema. This becomes painful somewhere in the low thousands of tenants.

Database per tenant gives the strongest isolation and suits enterprise customers with residency requirements. It is operationally heavy and rarely justified before you have those customers asking for it.

For most products, shared schema with row-level security enforced in the database is the right starting point. Enterprise customers who need more can be moved to dedicated databases later if the query layer was written sensibly.

Design billing as a core system

Billing is treated as an integration and behaves like a core domain. The gap between those two things is where revenue leaks.

Plan changes mid-cycle, usage that must be metered accurately, failed payments and dunning, refunds, and the reconciliation between your records and the payment provider's - all of these need real tests. A billing bug is not a normal bug: it is either lost revenue or an angry customer, and frequently both.

Keep your own record of what a customer should be charged rather than treating the payment provider as the source of truth. You need to be able to answer why an invoice is what it is without reading a third-party dashboard.

Draw these boundaries early

• Tenant context resolved once, at the edge, never re-derived deeper in the stack
• A permission layer that is consulted, rather than checks scattered through handlers
• An audit log written on the write path, not reconstructed from application logs
• An outbound event stream, so integrations do not require new endpoints each time
• A background job system, before you need it urgently

Defer this complexity

Equally important is what not to build early.

Microservices before you have teams that need independent deployment. The coordination overhead is real and the benefit is organisational rather than technical.

Elaborate caching before you have measured what is slow. Cache invalidation bugs are expensive and frequently introduced to solve a problem that a database index would have solved.

Multi-region deployment before a customer requires it. It multiplies operational complexity across every subsequent change.

Make the audit log a first-class citizen

Every SaaS product eventually needs to answer who changed what and when - for support, for security review, and for enterprise sales questionnaires.

Writing this at the point of change is straightforward. Reconstructing it later from application logs is unpleasant, incomplete and sometimes impossible. It is one of the few pieces of infrastructure genuinely worth building before it is needed.