Multi-tenant SaaS mistakes that show up after launch

Multi-tenant SaaS mistakes that show up after launch rarely appear in the sales demo: they appear when tenant B opens tenant A's invoice, when a support "god mode" forgets a filter, or when billing meters the wrong workspace. This is a buy-decision checklist for UK founders and product leads already shipping B2B portals or vertical SaaS, not a tenancy framework tutorial. The point is what to look for after go-live, and when a partner should review before trust breaks.

Mistakes demos miss

Missing tenant filter on one path. Most queries are scoped. One export, search, or webhook handler is not. Demos use one tenant. Production has twenty, and the forgotten path is the one finance uses on month-end when nobody is watching the error logs.

Shared file prefixes. Objects land in one bucket with guessable keys. Isolation lived only in the database. A signed URL or a support download crosses the fence.

Roles that span tenants. "Admin" means everything everywhere. Staff helping one customer can see another. Fine until a larger customer asks how isolation works and you do not have a clean answer.

Billing bolted on. Seats and usage tracked outside the tenancy model. Invoices and entitlements drift. Churn shows up as "your billing is wrong," not as an architecture debate in the engineering Slack.

Migrations without a tenant story. Schema changes run globally with no dry-run per tenant. One bad backfill hurts everyone at once, usually on a Sunday night when the on-call person is already tired.

Audit logs that omit tenant. You cannot prove who saw what. That matters the day a customer asks for evidence and legal wants a clear answer the same afternoon.

Support tooling without rails. Impersonation and raw SQL for "just this once." I've watched a well-meant support fix leak a list that should have stayed private.

Good enough vs stop and fix

Keep shipping if tenancy is enforced in a central place, files and admin paths are reviewed, and you have a test that fails when a filter is dropped. Stop and fix when any customer can see another's data, when support can cross tenants without a trail, or when you cannot explain isolation to a prospect who cares. "We'll harden tenancy later" is how later becomes a breach call or a lost enterprise deal.

When to call for a review

Keep iterating alone while the product is still one or two friendly tenants and you have someone who owns the tenancy rules. Call for help when you are about to onboard regulated or noisy neighbours, when a near-miss already happened, or when the codebase is opaque after an agency left and nobody wants to touch the tenancy layer. Eight Mile's SaaS work includes portals and multi-tenant products, plus rescue when isolation was "fine in staging" and ugly on the first noisy customer. Soft paths: software development for the next fixed-price release, security audit when the fear is access and data paths. You keep the code, the cloud accounts, and the data from day one, which matters when the review turns into a fix.

Fix before trust breaks

If multi-tenant SaaS mistakes that show up after launch are already keeping you awake, treat isolation as a product feature, not a refactor ticket buried under the next roadmap item that sales already sold.

Scope every path. Log every cross-tenant action. Prove it with a test that another engineer can run without folklore.

If you want a review, a fixed-price harden pass, or a rescue on accounts you own, contact Eight Mile and say what nearly leaked or what you cannot prove to a buyer.