Shared DB with tenant keys vs silos
Most B2B SaaS starts with shared schema plus strict tenant filters. Move to silos when compliance or noisy neighbors demand it—not because it sounds enterprise. MenuQR is a live example of the shared-schema path: vendors, menus, and Stripe subscriptions in one product with tenant isolation on every query. FFM used multi-tenancy so two enterprises could share a platform shape without mixing field data. Both are valid. Siloed databases per tenant are a later move when a customer’s contract or noisy query load requires it. Starting there on a $25k MVP is how you spend the budget on plumbing. Document the escape hatch: what would trigger a silo, and how exports would work.
AuthZ everywhere
Never trust the client’s tenant ID. Derive tenancy from the session and enforce it in queries, jobs, and webhooks. The UI hiding a row is not security. Webhooks from Stripe or WhatsApp must resolve the tenant from a signed mapping, not from a payload field a caller can spoof. Admin impersonation, if you have it, needs an audit trail. We fail CI on raw queries that do not go through the tenant helper. This is boring and it is why year-two incident reviews are shorter. If your ORM makes it easy to forget the filter, wrap it until forgetting is hard.
Migrations need tenant awareness
Backfills and cron jobs are classic leak points. Design batch jobs with the same isolation guarantees as the API. A night job that iterates “all rows” will eventually write the wrong tenant’s column because someone added a global flag. We chunk by tenant, log which tenant a job touched, and make a dry-run mode the default for destructive backfills. Schema migrations themselves should not require downtime that takes every tenant down if only one needs a backfill. Feature flags should be tenant-scoped when you roll out billing changes.
Billing and tenancy are the same problem
A subscription is a tenant state. Stripe webhooks must be idempotent and mapped to the right vendor. Seats, modules, and plan limits belong in the same isolation model as data. If a failed payment should freeze the guest menu, that is an explicit state machine—not a hope that the UI checks a boolean. We treat money flows as first-class architecture on fintech-adjacent work; SaaS billing is the same discipline at a smaller scale.
What we put in a SaaS Foundation
Architecture, tenant model, auth/roles, billing webhook integration, and a launch runbook—from $25,000, typically 8–16 weeks, as a starting range. Named delivery lead, staging, 100% IP, 90-day warranty. That package exists so founders do not pay for a rewrite when the first enterprise deal arrives. It is not a promise that every SaaS is $25k; AI, offline mobile, and multi-region compliance move the range. Read the MVP cost article for commercial framing; this piece is the technical one.
How to decide this month
If you have one customer and a spreadsheet, you might not need tenancy yet—but if you will sell a second vendor next quarter, put tenant keys in now. Changing a single-tenant app into a multi-tenant one is a modernization project, and we price it that way. Bring your object list (users, resources, billing) and the first enterprise questionnaire you have seen. We will tell you which isolation model matches, and what we will not pretend a shared database can satisfy.
Failure modes we see after launch
A reporting query that forgets the tenant filter, a webhook that trusts a body field, a support impersonation tool with no audit, a backfill that updates every row. These are not exotic. They are why we wrap the ORM and fail CI on raw access. MenuQR and FFM both required that discipline on day one, not after the first leak. If a large customer later needs a silo, export and cut over; do not sprinkle if-statements through the app. SaaS Foundation exists so this model is in the first milestone. Named lead, staging, IP, warranty. If your current app cannot name the tenant on every table, you are not ready for the second logo on the homepage—fix isolation before you buy ads.
