Multi-Tenant SaaS Starter: 8-Dimension Production Readiness Audit

What good looks like: Server-side on every request — layout loads verify org membership, actions re-derive membership fresh, services check before any write. No trust placed on client-provided org IDs.

What starters often ship instead: Most starters scope data at the UI layer only (filter by org in the client, render only that orgs data). A forged request with a different org ID returns another tenants data.

What good looks like: Token is hashed (SHA-256) before storage; only the hash lives in the database. Single-use via conditional UPDATE whose WHERE clause rejects already-accepted and already-revoked rows. Atomic claim prevents double-click membership.

What starters often ship instead: Many starters store the raw token in the database (a DB leak exposes every pending invite) and check used in application code rather than at the database level, creating race conditions.

What good looks like: At invite acceptance time, behind a swappable BillingAdapter seam. The accept action queries current seat count, compares against plan limit, and only then commits the membership.

What starters often ship instead: Common pattern: seat limit checked in the billing dashboard UI, not at the point of membership creation. Or checked in the invite-creation action (before the invite is accepted), so the seat could fill between creation and acceptance.

What good looks like: A single static capability matrix (owner, admin, member) with numeric ranks; every action calls requirePermission plus mayActOn/mayGrant. The matrix lives in exactly one place; adding a permission means adding one line.

What starters often ship instead: Starters often ship role strings with if/else checks scattered across components and actions. Adding a new permission means touching many files and hoping you did not miss one.

What good looks like: Append-only at the schema level — no UPDATE or DELETE grant exists on the table. Audit rows are written in the same service call as the mutation they record, with metadata that never contains raw tokens or secrets.

What starters often ship instead: Most starters either have no audit trail, or store audit rows in a regular table that application code can UPDATE — which defeats the purpose when a compliance buyer asks who changed what.

What good looks like: Sliding-window limiter runs BEFORE password hashing (pre-check), so blocked requests never touch the expensive hash. Keyed per IP and email for login, per IP for signup. Deterministic via injectable clock for testing.

What starters often ship instead: Many starters have no rate limiting at all. Those that do often run the check after the hash, meaning blocked requests still burn CPU on every attempt.

What good looks like: 77 vitest tests covering auth flows, invite acceptance with seat enforcement, RBAC hierarchy and permission checks, rate-limiter sliding-window semantics, and failed-login behavior. Tests exercise services and actions directly, not just UI snapshots.

What starters often ship instead: Common: a handful of smoke tests that verify login works and signup creates a user without testing the edge cases (expired invites, seat overflow, role escalation attempts, sliding-window expiry).

What good looks like: Rate limiter interface documents the multi-instance gap honestly and provides a seam (same interface, different backing store). Session storage and seat enforcement use the same database, not in-memory state.

What starters often ship instead: Starters that use in-memory sessions or in-memory rate limiting without documenting the gap — you discover it at the first deploy behind a load balancer, not at the README stage.