The multi-tenant mistakes that show up in year two

The architecture decisions that hurt a SaaS product rarely hurt at launch. They hurt in year two, once you have customers with meaningfully different data volumes, usage patterns, and support expectations than the ones you designed for.

Tenant isolation, decided too late

Row-level tenant IDs are the fastest way to ship a multi-tenant MVP, and often the wrong long-term choice once a customer asks about data residency or a noisy tenant starts affecting query performance for everyone else. We treat isolation strategy as a decision to revisit deliberately at each growth stage, not something to bolt on after an incident.

Background jobs without tenant fairness

A single large customer's batch job can starve the queue for everyone else. Fair scheduling per tenant is cheap to build early and expensive to retrofit once your job runner is load-bearing infrastructure.

Migrations that assume a quiet system

Schema migrations written against a small dataset behave differently at scale, locking tables, timing out, or taking down write paths during business hours. We test migrations against production-sized data before they ship, not after they fail.