Most multi-tenant SaaS rewrites don't happen because the code was bad. They
happen because a boundary was drawn wrong on day one — and by the time it
hurts, it's load-bearing. This is the checklist I run before writing a single
screen, distilled from shipping multi-tenant platforms across the Gulf, US &
UK. Use it as a pre-build gate: if you can't answer a question, that's the
next conversation to have — not the next feature to build.
01Tenancy model — decide before anything else
Isolation strategy chosen and written down: shared schema (tenant_id), schema-per-tenant, or database-per-tenant — each has a different blast radius and cost curve.
Tenant resolution path defined: subdomain, path, header, or token claim — resolved in middleware, not controllers.
Every query is tenant-scoped by default, not by developer discipline. A global scope that fails closed (no tenant = no data).
The "noisy neighbor" question answered: can one tenant's load degrade another's? What's the ceiling?
Cross-tenant admin access is a separate, audited path — never the same code path as tenant users.
02Identity, roles & access
Roles modeled as first-class concepts, not booleans that multiply.
Separate auth guards for distinct actor types (admin / company / customer) rather than one overloaded user table.
Permission checks centralized in a policy layer, not sprinkled in views.
Tenant + role together decide access — a valid user in the wrong tenant sees nothing.
Impersonation / support access is logged, time-boxed, and reversible.
03Data & billing awareness
Billing is a first-class concept in the data model from day one — plans, limits, usage, and the seams to meter them.
Usage-limiting is enforceable (seats, API calls, storage) without a schema migration later.
Schema first, indexes second — but the tenant_id composite indexes that matter at scale are identified now.
Soft-delete & data-retention policy decided per entity.
Tenant data export & deletion possible (GDPR/offboarding) without a manual DBA operation.
04Real-time & concurrency (if applicable)
The server is the single source of truth for ordering — never the client.
Atomic operations for contended state (Redis atomic increments for counters, bids, inventory).
A push layer (WebSocket/SSE) mirrors state to watchers — with a latency target you actually measure.
Idempotency keys on anything retryable (payments, webhooks).
Backpressure & reconnection handled — what happens when 200 clients reconnect at once?
05Integrations & money
Payment gateway(s) chosen per region and abstracted behind one interface so a second gateway isn't a rewrite.
Webhooks verified, idempotent, and queued — never processed inline on the request thread.
ERP/CRM sync direction defined (one-way vs bidirectional) with conflict resolution decided before the first sync.
External calls have timeouts, retries, and a circuit breaker — a slow third party can't take you down.
06Delivery & operations
Deploy topology decided: environments (alpha/beta/prod) and a pipeline that survives a Friday deploy.
Migrations safe to run by someone who isn't you, at 2 a.m. (reversible, non-locking where it counts).
Observability from v1: structured logs, error tracking, and the 3–5 metrics that signal health.
Feature flags so vertical slices ship early and dark.
A runbook exists — the handoff is part of the work, not an afterthought.
07The "can't cheaply undo" list
Get these right on day one. Everything else you can refactor.
Tenant isolation strategy
Auth / guard structure
Billing in the data model
Server-authoritative real-time ordering
API contract & versioning
Deployment topology
Want a second pair of eyes on yours?
I do architecture reviews and fixed-scope builds for real-time,
multi-tenant SaaS. A 30-minute scoping call is free — and often saves a
six-month rewrite.