White-label for your agency: sell AI and software to clients without rebuilding everything every time

Every client a project from scratch: that’s how the margin dies

If you run an agency — digital, communications, consulting — you know this trap even if you’ve never named it. Every client is a project from scratch. Client A wants a tool, you build it. Client B wants something similar, but “a bit different”, and you rebuild it almost from the ground up. Client C, again. Every time you start over, remount, redo. And your margin, project after project, dies — because you’re selling hours, and hours don’t scale.

The maths is merciless. If every client costs you X hours of build and you sell at X hours + margin, your profit grows only if you sell more hours, which means hiring or working more. There’s no leverage: doubling revenue means doubling the work. That’s the glass ceiling of every agency that sells custom projects one at a time — you work a huge amount, revenue goes up, but the margin per project stays thin because you always start from zero, and at some point you can’t grow without becoming a factory of hours.

There’s another way, and it’s what separates agencies that scale from agencies that stay stuck: build once, sell many times. Instead of rebuilding for every client, you build one product — a tool, a platform, a service based on AI or software — and you sell it to many clients, each under their brand, as if it were theirs. That’s white-label: the same thing underneath, many faces on top. Client A sells it to their clients as “A’s product”, client B as “B’s product”, and you behind maintain one platform. The margin, suddenly, stops dying on every project: you build once, you collect many times.

This article is for you if you run an agency and you can feel the hours ceiling. We’ll talk about what white-label really is (and what instead is a dangerous mess sold as white-label), how it’s built underneath, who does support, how you price it, and — honestly — when white-label doesn’t pay. Because it isn’t the answer for everyone, and you’d rather know before you throw yourself in.

What white-label really is: brand, domains, separate data

Let’s be clear, because “white-label” is a word used for the wrong things. Real white-label means something precise: the same product wears different brands, and every client is isolated from the others. Three conditions, all of them necessary.

• The brand is the client’s. When client A enters the product — and when their clients enter it — they see A’s logo, A’s colours, A’s name. Not “powered by your agency” in small print: the face is entirely A’s. For their users, it’s A’s product. That’s the point: the client can resell it as theirs, and that’s what gives them value (and what justifies your price).
• The domain is the client’s. The product lives at an address that belongs to A (their domain, or a subdomain of theirs), not at an address of yours. It reinforces the idea that this is “A’s stuff” and not a service rented from someone else.
• The data is separate. And here we get to the serious heart of it: client A’s data and client B’s data never mix. A sees nothing of B, B sees nothing of A, and neither of them sees anyone else. Every client lives in their isolated space, as if they had the product all to themselves — even though underneath the platform is one.

This third condition — data separation — is what distinguishes real white-label from a dangerous mess, and it’s the subject of the next section, because that’s where the damage gets done. But the underlying idea is this: a different face for each one, an isolated space for each one, one engine underneath. If the client’s brand is missing, it isn’t white-label (it’s your product that you rent). If separate data is missing, it isn’t white-label: it’s a time bomb. It’s the same principle I describe in launching a white-label AI product: repeatability comes from building the product designed to wear many skins from the start, not from sticking a logo on something made for a single client.

What a mess is, instead: same database, same logs

Now the danger — the one that hurts you, and that you have to understand before you start. Badly done white-label isn’t “slightly worse white-label”: it’s a serious risk dressed up as a clever solution. And the typical mistake, the one agencies that improvise make, is putting all the clients in the same space, mixed together.

Imagine you build the tool for client A, and then, for client B, instead of giving them a space of their own, you make them use the exact same system with the same mixed data, distinguishing A from B with a label. It looks like a brilliant saving: one system, less work. It’s a trap, for reasons that explode at the worst moment:

• The data leak. If all the data sits mixed in the same place and you distinguish it only with a label, one error is enough — a forgotten filter, a bug — for client A to see client B’s data. In white-label this is catastrophic: A’s clients and B’s clients may well be competitors, and showing one the other’s data isn’t an annoying bug, it’s a legal and reputational disaster that shuts you down. With data that’s actually separate, this can’t happen by construction.
• The mixed logs. When something goes wrong and you have to understand what happened, if every client’s traces are piled together, investigating is a nightmare — and you risk exposing one client’s information while you fix another client’s problem.
• The “touch” that hits everyone. If everyone shares the exact same space with no isolation, a problem caused by one client (an abnormal load, a heavy operation) can degrade the service for all the others. One client takes the others down with them.
• The impossibility of leaving clean. If client B wants to leave you and take their data, but their data is mixed with everyone else’s, pulling out only theirs in a clean way becomes a risky job — and maybe in the contract you had promised they could.

The difference between real white-label and a mess is all in the isolation. It isn’t a technical detail to postpone: it’s the foundation. White-label built without real data separation is a house built on sand — it stands until the wave comes, and the wave always comes. This is exactly the kind of thing where you need someone who understands the architecture underneath, not someone who pastes logos: because the error doesn’t show until it’s too late, and when it shows it’s irreparable.

One core, many skins, rules per client

So how is real white-label actually made? The model boils down to this: one core, many skins. One engine, shared, that you build and maintain once; and on top, for each client, a “skin” (the brand, the colours, the domain) and an isolated data space. In technical jargon each client is a tenant — a tenant who has their own apartment in a condominium: shared structure, separate home.

What the core shares and what is per-client:

• The core (one, shared): the product logic, the features, the engine. You build it once. When you improve it — you add a function, you fix a problem — all the clients benefit together, with a single update. That’s the margin lever: one piece of work, many beneficiaries.
• The skin (one per client): brand, colours, logo, domain. You change it from a single point, without touching the core. Adding a new client means “mounting a new skin”, not rebuilding the product. That’s what makes it scale: the tenth client costs a fraction of the first.
• The data space (one isolated space per client): each one’s data separate from the others, as above. Isolation by construction.
• The per-client rules: and here’s the subtlety that makes the model usable in real life. Clients are never 100% identical: A wants that feature, B doesn’t want it, C wants a different limit. Well-made white-label allows rules and configurations per client — what’s on for whom, which limits, which variants — without forking the code into different versions. One core only, but it configures differently for each one. If instead for every “but this client wants…” you have to make a separate version of the product, you’re back to the project from scratch: the model snaps.

Building this well — the configurable core, the skins, the data isolation, the per-tenant rules — is the part that needs a hand that understands the architecture: data (the isolated spaces), backend (the core and the per-tenant rules), frontend (the brandable skins). It’s the same reason a frontend for a software house has to be thought with a design system that allows many faces from a single point: without that base, white-label is a rebuild for every client, and the promise of scale collapses. The value of a single pair of hands here is huge, because all these pieces have to lock together from the start — adding them later to a product born for a single client is almost like rebuilding it.

Who does support: L1 is you, L2 is whoever builds

A practical question that decides whether the model is sustainable: when a client has a problem, who answers? Because with many clients, problems arrive, and if it isn’t clear who handles what, support either eats you or drives the clients away. The healthy split is two levels.

• The first level (L1) is you, the agency. You’re the one who has the relationship with the client, you’re their face. When client A has a question, they call you — they don’t even need to know that behind there’s someone else who built the platform. L1 is: answering usage questions (“how do I do this?”), managing the relationship, filtering what’s a real technical problem and what’s a “I didn’t understand how it works”. Most requests stop here, and you handle them because you know the client and the product from the usage side.
• The second level (L2) is whoever built the platform. When the problem is genuinely technical — something doesn’t work, there’s a bug, the core needs an intervention — L1 (you) passes it to L2 (whoever builds and maintains the core). The client doesn’t see it: for them you’re the one solving the problem. Behind, L2 puts their hands where it matters.

This split is what makes the model livable for an agency. You stay the face and the relationship (which is your trade and your value), you handle the bulk of the requests, and you delegate to L2 only the real technical problems. You don’t have to become a software company with a technical department: you lean on whoever does the technical work, while you keep the commercial relationship. The pact has to be defined clearly from the start: what you handle (L1), what goes to L2, with what timelines (the SLAs I talked about for maintenance), and how. White-label without a clear support agreement is white-label that, at the first serious problem, finds you unprepared in front of the client — and in front of the client you can’t afford that, because for them the face is you.

The price to your client versus your cost

Let’s talk money, because white-label is, in the end, a margin game, and you have to understand it properly so you don’t price at random. There are two numbers, and the distance between them is your profit.

• Your cost is what you pay to have and maintain the platform: the build cost (once), plus the cost of keeping it alive and of managing the tenants over time (L2, the infrastructure). Spread across many clients, the cost per client falls as you add clients — because you pay for the core once and you divide it across everyone. That’s the economy of scale that makes white-label interesting.
• The price to your client is what you charge client A, who in turn resells it (or uses it) with their clients. Client A pays gladly, because for them it’s a product they can put on the market under their brand without having to build it — you save them months and a huge investment. The value they perceive isn’t “your cost”: it’s “what it would cost them to build it themselves” (a lot) or “what they make by reselling it” (their margin). Price on that, not on your cost.

The margin lever is the distance between the two, and it grows with the number of clients: the more tenants you put on the core, the more the cost per client falls while the price stays. The healthy model is often a recurring fee per client (a monthly subscription per tenant) plus, optionally, an initial activation cost. Recurring is the beautiful part: you build once and you collect every month from every client, with a low marginal cost per client. That’s how an agency breaks the hours ceiling — it moves from “I sell hours” to “I have a platform that generates recurring revenue from many clients”. But watch it: recurring also brings a recurring cost (maintenance, support), so the price has to cover it with margin, not just break even — a common mistake is pricing looking only at the build cost and forgetting the cost of keeping the whole thing alive.

Selling AI in white-label: a repeatable product, not unrepeatable magic

Today a lot of agencies want to “sell AI” to their clients, and it’s excellent ground for white-label — provided you understand what you’re actually selling, because here enthusiasm makes people make mistakes.

AI is particularly suited to the “one core, many skins” model for a precise reason: the repeatable value sits in the product around the AI, not in the model itself. The AI model, on its own, everyone can use — that isn’t your product. Your product is the thing built around it: the flow, the interface, the client’s data the AI works on, the rules, the controls, the way the AI’s answer becomes something useful and checkable for that client. That’s the core you build once and resell to many, each with their isolated data and their skin. An assistant that answers on the client’s documents, a tool that generates drafts from their material, an analysis of their numbers: the same engine, many clients, each putting their data into their space.

But precisely because you sell AI to many clients under their brand, the AI boundary I hold everywhere becomes here a commercial responsibility, not only a technical one: AI prepares, proposes, finds — it doesn’t decide on its own the things that matter. If you resell to ten clients a tool that “decides automatically” or that generates answers with no way to verify where they come from, you multiply by ten the risk of an error that, in front of the end client, falls on you (you’re the face, remember). Well-made AI white-label sells tools where AI accelerates and assists and the person stays at the wheel on the delicate decisions, and where answers are traceable to the source. It’s the same principle that holds for an LLM-based product versus a toy chatbot: the value, and the serious sellability to many clients, sits in the solid product around the AI, not in the promise of magic. Whoever resells unrepeatable magic sooner or later pays the bill multiplied by the number of clients.

The contract: responsibilities, uptime, data

With many clients on a single platform, the contract isn’t a detail: it’s what protects you when something goes wrong — and with enough clients, sooner or later something goes wrong. Three things have to go in black and white, both in your agreement with whoever builds the core, and in your contracts with the clients.

• Responsibilities: who answers for what. If the service has a problem, whose is the responsibility toward the end client? You (L1) are the face, but the technical responsibility for the core is whoever builds it (L2). This chain has to be defined: what you guarantee to your client, what L2 guarantees to you. Without clarity, at the first serious problem people bounce the blame while the client is angry at you.
• Uptime: how much the service has to stay up. You sell a service that clients (and their clients) will use: if it goes down, they don’t work, and they call you. You have to agree how much it has to stay up, what happens if it’s down, who steps in and in how much time. You guarantee this to the clients and you must have it guaranteed to you by L2 — you can’t promise the client an uptime you yourself haven’t been guaranteed by whoever holds the core.
• The data: whose it is and what happens if you part ways. Client A’s data is A’s: that has to be written. And you have to define what happens if A wants to leave — they must be able to get their data back (isolated, so extractable clean). You also have to make clear what happens if you stop, or if L2 stops: clients must not be held hostage. Continuity and data portability are what make your service reliable in the eyes of serious clients.

The thread that ties these three things is trust: a client who entrusts you (and the platform behind) with their data and their operations, and who maybe resells them to their clients, needs to know there’s a clear structure of responsibility, continuity and ownership. A vague contract here scares serious clients and exposes you at the first incident. A clear contract, instead, is itself a sales argument: it shows you’re a serious thing, not an improvisation.

When NOT to do white-label

And now the honesty that makes the article worth reading: white-label is not the answer for everyone. Building it costs more and takes more head than a single project — the isolation, the configurable core, the support structure — and it only makes sense if you then repeat it across many clients. If you don’t repeat it, you’ve paid for the complexity of scale without collecting its benefits. Let’s see when it doesn’t pay.

• If you have a single vertical you don’t repeat. If your tool serves a very specific type of client and you don’t have many similar clients in front of you to resell it to, white-label is over-engineering: you pay for repeatability and then you don’t repeat. Better a single project done well.
• If every client is too different. White-label works when clients share 80% and differentiate on the 20% (the skins, the rules). If instead each one wants something radically different, the shared core doesn’t hold: you end up making separate versions, meaning projects from scratch disguised as tenants. If there isn’t a real common nucleus, there is no white-label.
• If you don’t have the channel to sell it to many. White-label pays back with numbers: many clients on the core. If you don’t have (or aren’t building) a way to bring many clients onto the platform, the lever doesn’t trip. Scale is the premise, not an automatic result.
• If you aren’t ready to do L1 seriously. Selling to many clients means supporting many clients. If you don’t have the structure to do first-level support in a serious way, many clients become many problems, and the model turns against you.

The honest rule: white-label is for whoever has a repeatable product and a channel to sell it to many. If you have both, it’s the lever that breaks the hours ceiling and turns your agency from a project factory into a platform that scales. If you’re missing one of the two — the repeatability or the channel — then, for now, a single project done well is the right choice, and building white-label would be paying for a scale that doesn’t arrive. Better to know beforehand. This reasoning about when it makes sense to repeat and when it doesn’t sits at the centre of the web and digital product cluster: a product isn’t better than a project in the absolute — it’s better when you repeat it.

If you have an agency that feels the hours ceiling and you can already see a repeatable product in your projects, the first step is to understand whether the repeatability and the channel are actually there. Look at how I work or drop me a line and we’ll talk it through — including to tell you honestly “not yet”, if that’s the case.

It’s for you if / it isn’t for you if

It’s for you if:

• you have an agency and you rebuild similar projects from scratch for client after client, with the margin dying;
• you see in your projects a common nucleus you could build once and resell to many;
• you have (or you’re building) a channel to bring many clients onto the platform;
• you want to move from “I sell hours” to recurring revenue from many clients under their brand;
• you’re ready to do the first level of support and to keep the relationship with the clients.

It isn’t for you if:

• you have a single vertical that’s very specific and you don’t repeat it: here white-label is over-engineering, better a single project;
• every client is radically different from the others: without a real common core, you end up doing projects from scratch in disguise;
• you don’t have the channel to sell to many: scale is the premise, and without numbers the lever doesn’t trip;
• you aren’t ready to support many clients: many clients without a support structure become many problems.

8 questions from whoever is about to sign

1. What’s the difference between real white-label and “I put a logo on top”? Real white-label has three things: the client’s brand, the client’s domain, and isolated data per client. If real data separation is missing, it isn’t white-label: it’s a dangerous mess where one error can show one client’s data to another. Isolation is the foundation, not a detail.

2. What does “one core, many skins” mean? One engine that you build and maintain once (the core), and for each client a branded face (the skin) plus an isolated data space. You improve the core once and everyone benefits; you add a client by mounting a skin, not by rebuilding. That’s the lever that scales the margin.

3. What if clients want different things from each other? Well-made white-label allows rules and configurations per client (what’s on for whom, which limits) without creating separate versions of the code. It works if clients share 80% and differ on the 20%. If each one wants something radically different, the model doesn’t hold.

4. Who does support for the clients? Two levels: the first (L1) is you, the agency, who keep the relationship and handle usage questions; the second (L2) is whoever builds and maintains the core, to whom you pass only the real technical problems. The client sees only you. The pact has to be defined clearly from the start, with agreed response times.

5. How do I price the service to my clients? Not on your cost, but on the value for the client: what it would cost them to build it themselves (a lot) or what they make by reselling it. Often a recurring fee per client plus an initial activation. Remember to cover with the price the recurring cost of maintenance and support as well, not only the build.

6. What does the contract have to say? Three things: the responsibilities (who answers for what in the you-L2-client chain), the uptime (how much the service stays up and who steps in if it falls), and the data (whose it is, how you get it back if you part ways, what happens if you or L2 stop). A clear contract is also a sales argument with serious clients.

7. How much does it cost to build white-label compared to a single project? More, because data isolation, the configurable core and the tenant structure need more architecture from the start. It only makes sense if you then repeat it across many clients: the complexity of scale pays back with the numbers. On a single client, it’s over-engineering.

8. When should I NOT do it? When you have a single vertical you don’t repeat, when every client is too different (no common core), when you don’t have the channel to sell to many, or when you aren’t ready to support many clients. If you’re missing the repeatability or the channel, for now a single project done well is the right choice.