Some of the most useful software businesses are invisible as software businesses: a company that serves fifty local franchises, each with its own branded website, own customer list, and own staff logins, all running on a single application. That design is called multi-tenancy, and it is the difference between operating one product and operating fifty copies of one.
The alternative, one installation per customer, feels simpler at first and becomes the thing that kills the business at scale. Fifty copies means fifty deployments for every fix, fifty databases drifting out of sync, and a security patch that takes a week to roll out instead of a minute. Multi-tenancy centralizes all of that: fix once, everyone is fixed.
The engineering weight sits in one place: isolation. Every query, every file path, every background job must be scoped to the requesting tenant, so that one customer can never see another's data, not even by accident, not even by a crafted URL. This is the part to get right on day one, because retrofitting isolation into a single-tenant codebase is among the most expensive refactors in the trade.
When does it pay for itself? Roughly when you expect customer three. Two installations can be managed by hand. By the tenth, the single-codebase decision is either your margin or your biggest regret, and which one was decided back at the architecture stage.
