Building a SaaS Product: Architecture and Delivery Decisions

Tenancy is the week-one decision

Tenancy determines where the boundary between customers sits. Everything else in a SaaS architecture is shaped by that choice: query structure, backup and restore, deployment, the blast radius of a bug, and whether a single customer can be moved, exported or deleted without touching anyone else.

It is hard to change later because it is not one decision expressed in one place. By the time there is a product, the assumption is in every query, every migration and every operational procedure. Changing it means a migration of live customer data with no acceptable downtime.

That makes it worth more thought than it usually gets in week one, when the pressure is to get something in front of users. An hour on this is cheap; a year in is not.

Three models and what each costs to run

A shared database with a tenant identifier on every row is the cheapest to operate and the fastest to build. One schema, one migration, one connection pool. The risk is concentrated in a single place: every query must filter by tenant, and one that does not is a data breach. Enforce it in a shared data-access layer rather than relying on developers remembering, and test for it specifically.

A schema or database per tenant gives real isolation and makes per-customer backup, restore and deletion straightforward. The cost is operational: migrations run many times, connection management gets harder, and tooling that was trivial with one database becomes a job of its own at a few hundred.

A full instance per tenant is what enterprise buyers sometimes insist on, with its own infrastructure and often its own region. It is the most expensive to run by a wide margin and only makes sense when the contracts justify it. If you expect to need it, keep deployment fully automated from the start, because doing this by hand does not scale past a handful.

For most products starting out, a shared database with a disciplined data-access layer is the right answer, provided you have thought about the migration path should a large customer later require isolation.

Billing state versus application state

Your billing provider knows what a customer pays for. Your application knows what they can do. These are two separate sources of truth and they will disagree, usually at the least convenient moment.

Payment fails and the subscription lapses while the customer is mid-task. A plan is upgraded in the billing portal and the application has not caught up. A refund is issued, a trial is extended manually, a discount is applied out of band. Each is routine, and each is a divergence.

Treat entitlements as application state that is updated from billing events, rather than querying the provider at the point of use. Make the webhook handling idempotent, since providers retry and occasionally deliver events out of order, and reconcile periodically against the provider's own record.

Define the degradation path explicitly. When payment fails, what exactly happens, and when? Immediate lockout loses customers over an expired card. Indefinite access invites abuse. A grace period with clear notice, then read-only access, then suspension, is a pattern that works — but it has to be designed rather than discovered.

Self-service onboarding as a growth constraint

If a new customer cannot reach value without someone from your team, your growth rate is capped by your team's capacity. That may be entirely acceptable for an enterprise product with a long sales cycle, and it is fatal for a product whose pricing assumes volume.

The constraint is rarely signup. It is the gap between account creation and the first moment the product is actually useful, which usually requires the customer's own data. Importing it, connecting a system, or inviting colleagues is where new accounts go quiet.

Instrument that path and look at where people stop. An empty state that explains what to do next, sample data to explore, and an import that tolerates an imperfect spreadsheet will do more for conversion than most feature work.

Usage metering you will wish you had

Record what each tenant does from the first release: actions taken, records held, storage consumed, API calls made, users active. It is straightforward to add early and genuinely awkward to backfill, because the history simply does not exist.

You need it for several things at once. Usage-based pricing is impossible without it. Capacity planning is guesswork without it. So is knowing which customers are at risk, because a steady decline in activity is the clearest warning you will get before a cancellation.

Keep metering separate from analytics. Analytics can lose an event without consequence; metering that feeds invoices cannot. If billing depends on these numbers, they need the durability and the auditability of financial data, including the ability to explain a figure to a customer who disputes it.

Scoping a first version

Scope the first release around the single workflow that makes someone pay, and build that one properly rather than building six at demonstration quality. A product that does one job well has a reason to exist; one that does six adequately competes on feature lists with incumbents who have more of them.

Some things cannot be deferred even in a first version, because retrofitting them is disproportionately expensive: authentication and tenant isolation, a backup you have actually restored from, audit logging, and the ability to export a customer's data. The last one matters commercially as well as legally — buyers ask, and an honest answer builds more trust than a vague one.

Much else can wait. Granular permissions, single sign-on, an API, white-labelling and advanced reporting are all real requirements eventually, and all of them are better built once a paying customer has described exactly what they need rather than imagined in advance.