You have a tool that works for one customer, and you want to sell it to ten more. That is the right instinct: the development is already paid for, and each additional customer costs less than the first. What remains looks like a technical question, but the answer is a commercial one: does every customer get their own application, or does everyone share the same one?
Both models exist, they have different names, and they do not cost the same.
The white-label model: one app per customer
One codebase, but as many published applications as you have customers. Each one gets their own: their name, their logo, their colours, their own store listing. Their users do not know — and do not need to know — that the same base runs ten other organisations.
What it gives you. Your customer exists in the eyes of their own members. For an association, a club or a franchise, that is often the whole argument: the tool does not look like a subscription taken out with a third party, it looks like something the organisation built for its own people.
What it costs you. Every customer is one more release. A security update means ten submissions across two app stores, ten editorial reviews to pass, ten sets of screenshots to keep current. The real bill for white-label is not in the code, it is in distribution.
The multi-tenant model: a single installation for everyone
One application, one server, one database. Customers live side by side, partitioned: each sees only their own data. This is how nearly all subscription software is built.
What it gives you. One more customer costs almost nothing: no release, no extra server, no separate version to maintain. You fix a defect once and everyone benefits the same day.
What it costs you. Data partitioning becomes the single most important question in the project. One mistake — a query that forgets to filter on the right customer — and one organisation sees another’s data. That is the kind of incident a business does not recover from, and it cannot be handled at the end of the project: it is decided in the first weeks, in the structure of the data itself.
The question that actually settles it
It is not a technical one:
Does your customer need to appear as the publisher of the tool to their own users?
If yes — association, club, federation, franchise, branch network — white-label is the answer, and the distribution cost that comes with it has to be accepted.
If no — your customers are comfortable using off-the-shelf software, the way they are comfortable with their accounting package — multi-tenant is almost always the right choice, and the only one that lets you add a customer without spending a week on it.
The two combine perfectly well, incidentally: it is common for a single multi-tenant server to feed several white-label applications. That is even the most comfortable arrangement — provided it was decided before the first screen was written.
The trap that kills both models
It is the same in both cases, and it is always committed for good reasons.
A customer asks for an adjustment. It is not much. You code it “just for them”, in their version. Six months and three customers later, there are four variants of the same software, and every fix has to be written, tested and released four times. The product died before it became profitable.
The discipline that prevents it fits into one rule: nothing customer-specific enters the product code. A customer owns a configuration file and a folder of images. Everything else is generic — and when a request cannot be phrased generically, it has almost always been misunderstood.
We apply this rule to our own products: a suite branded per association on one side, a multi-tenant platform for clubs on the other. They are two different answers to the same question, and the choice was made before the first line of code.
Is that where you are? This is exactly the kind of decision an architecture and advisory phase handles: a few days at the start of a project that determine what your tenth customer will cost. Let’s talk about it — the first conversation is free.
