Multi-tenant architecture is usually explained from the provider's side: one codebase, one deployment, many customers, better margins. That is accurate, and it is only half the picture. The client experiences the same architecture as a set of constraints, and the gap between those two views is where most SaaS relationships go wrong.
For the provider, multi-tenancy means shipping a fix once and having every customer receive it. It means predictable infrastructure costs and a single system to reason about. It also means every decision is a decision for everyone: a schema change, an interface redesign, a pricing model — none of it can be applied to one customer without becoming a special case that erodes the entire advantage.
For the client, the same architecture means their data lives beside other companies' data, separated by application logic rather than by physical boundary. It means they cannot defer an upgrade that breaks their workflow. It means a feature they urgently need waits behind a roadmap shaped by other customers. None of that is a defect. But it is rarely stated plainly during a sales conversation.
White-label deployments complicate this further, because they promise the client something multi-tenancy is structurally poor at: the appearance of a dedicated product. It works when the customisation is presentational — branding, domain, terminology. It fails when the client reads that promise as extending to behaviour, and asks for a workflow that contradicts the shared model.
The honest approach is to be explicit about which layer is negotiable. Presentation: yes. Configuration within defined bounds: yes. Core data model and business rules: no, and here is why. Clients accept constraints they understand far better than surprises they discover in month eight. Setting that expectation early is worth more than any feature you could ship instead.