Multi-tenancy decisions you cannot reverse later

Multi-tenancy decisions are deceptive because the first customer or two never expose them. A shared schema with a tenant column works fine at that scale: the strain only shows up once billing, data isolation and noisy-neighbour performance all start mattering at the same time, usually right when the business can least afford to stop and rebuild.

Most SaaS products do not fail at launch. They fail at the tenth customer, when the shortcuts start compounding.

The decisions that are hardest to reverse are the ones made implicitly: a table without a tenant boundary enforced at the database layer, an assumption baked into a background job that only one tenant's data will ever be processed at a time, a piece of business logic that quietly relies on there being exactly one instance of something. None of these look like architecture decisions when they're made. They look like the fastest way to ship the feature in front of you.

Our approach is to make the tenancy model an explicit, first-class decision before the first feature is built on top of it, not a retrofit. That includes deciding, in writing, how isolation is enforced, how a tenant's data is deleted completely on request, and how a single noisy tenant is prevented from affecting everyone else's experience.

It costs more time in week one. It costs far less time in year two, which is the trade we'd rather make on behalf of a client than have them discover the alternative themselves.