Fig. 15 — Multi-tenant systems
SaaS development
The parts that make software a SaaS — tenancy, subscriptions, billing — are the parts that decide what it costs to run for years. They are worth getting right in the first month.
Tenancy is a decision, not a detail
How tenants are separated — a row-level key, a schema each, a database each — sets the cost of every query, every migration and every support request from then on. It is close to irreversible once there is data, so we settle it before writing the first feature, against your real expectations for customer count and data volume rather than a generic default.
- Isolation chosen against your numbers, with the trade-off stated in writing
- Every query scoped to a tenant by construction, not by remembering to add a filter
- Migrations that run across tenants without taking the product down
- Per-tenant configuration that does not become a fork of the codebase
Billing, including the parts that go wrong
Subscriptions are easy while everyone pays on time. The work is in the rest: webhooks that arrive twice, or out of order, or not at all; a card that fails on renewal; a plan change mid-cycle; a trial that ends while someone is using the product. We build for those cases from the start, because retrofitting them means touching money that is already moving.
- Webhook handling that is idempotent — the same event twice changes nothing twice
- Trials, upgrades, downgrades and proration treated as normal flows
- Failed payments with a defined path back, not a silent lockout
- Billing state derived from the provider, never guessed locally
Changing a product that is already live
A SaaS is never finished, so the question is not whether the first release is good but whether the twentieth is cheap. That is why we care about typed contracts shared between client and server, migrations that run identically everywhere, and a deploy that stops itself when something is wrong — the things that decide whether a year-old codebase is an asset or a tax.