SaaS products

A SaaS product has three problems that a single-tenant application never faces: keeping one customer's data away from another's, deciding what each role inside a customer may do, and knowing at any moment who is actually entitled to use the product.

Tenant isolation is a property of the data model, not a condition appended to every query. When the boundary lives in one place — a scoped connection, a policy in the database, a repository no query can bypass — a forgotten filter in a new feature is an error rather than a leak. When it lives in a hundred where clauses, it is only a matter of time.

Billing is state, not a webhook. Trialling, active, past due, cancelled and paused are states with defined transitions, and access follows from them. A product that infers entitlement from the last message the payment provider happened to deliver will eventually let a cancelled account in and lock a paying one out, usually on a weekend.

The rest is the unglamorous part that decides whether a product survives its first hundred customers: usage that can be counted and invoiced without a spreadsheet, an audit trail of who changed what, an export a customer can take with them, and a deletion path that actually removes data. None of it is visible in a demo. All of it is visible in the first year of operation.