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.

It is worth being honest about where the effort actually goes. The interface is the visible part and rarely the expensive one. The expensive part is the order of side effects: when someone presses pay, the system has to confirm with the provider, reserve the thing being sold, store the order, send the confirmation and update the totals, and it has to reach a correct final state whichever of those steps fails halfway. Getting that sequence right is most of what separates a demo from a product.