Most white-label agreements between agencies and technical partners start the same way: with good intentions and no paperwork at all.
Someone knows someone. A project comes up. It feels like a good fit. And work begins on the understanding that “we’ll sort out the details later.”
The first project often goes well, because problems don’t have time to surface. The trouble comes with the second one, or the third, or the day something goes wrong and nobody is sure who is responsible for what.
A well-structured agreement isn’t bureaucracy: it’s what separates a relationship that scales from one that falls apart at the first complication. If you’re still deciding whether the model is right for you, you may want to read first about what white-label development is and how it protects your agency’s margin.
First things first: define exactly what you’re agreeing to
It sounds obvious, but it isn’t. “We work together on technical projects” can mean very different things depending on who’s reading it.
A useful white-label agreement spells out, from day one, at least these 3 elements.
What kind of projects the agreement covers. Everything the agency needs on the technical side? Only custom development? Maintenance too? Projects of any size, or only above a certain scope? It’s also worth writing down what’s out: knowing in advance when to say “we don’t do that” prevents impossible commitments.
Who does what on each project. The agency manages the client relationship and defines the requirements. The technical partner builds and delivers the work. But there are gray areas: who talks to the client when technical questions come up? Who decides whether a scope change is feasible? Who keeps track of deadlines? These questions need answers before they come up, not while the client is waiting.
How communication works. Which channel? What response times? How are decisions documented within each project? Plenty of relationships that work on the first project break down on the fourth because nobody set up how information flows.
The financial model: 3 options and what they imply
Money is where most misunderstandings happen if it isn’t clearly defined. There are 3 common models, each with its pros and cons.
Markup on cost. The technical partner quotes a price to the agency, and the agency passes it on to the client with whatever markup it sees fit. It’s the cleanest model for the agency: it has full control over its margin and doesn’t have to share what it charges the end client.
The risk is that the agency squeezes the partner’s price to compete. A partner working on very thin margins ends up prioritizing other clients during busy periods, and that shows in the deadlines.
Commission per project. The technical partner invoices the end client directly and pays the agency an agreed commission for every project that comes through it. It’s less common in pure white-label, but it works when the agency acts more as a broker than as the project manager.
The problem is confidentiality: if the partner invoices the client, the client knows the partner exists. That isn’t always an issue, but you need to factor it in.
Fixed fee for reserved capacity. The agency pays the technical partner a fixed monthly amount in exchange for a guaranteed amount of work capacity. Not project by project, but as a stable structure.
It’s the model that gives both sides the most stability once the relationship is mature and the workload is predictable. That said, the agreement should spell out what happens to hours that go unused in a month (whether they’re lost, rolled over or offset) and how anything beyond the reserved capacity is billed.
There’s no model that’s better in the abstract, only one that fits each stage of the relationship better. What matters in all of them is that the partner acts as a technology partner and not just a supplier of hours.
Whatever the model, put the payment terms in writing: how soon the agency pays the partner and whether that payment depends on the end client having paid first. In Spain, the late payment law caps payment terms between businesses at 60 days.
Intellectual property: the most overlooked point and the one that causes the most trouble
When a project is done and the client’s website is up and running, who owns the code?
The answer seems obvious: whoever paid for it. But without an explicit agreement, the legal answer isn’t that clear. In Spain, the transfer of exploitation rights over software must be made in writing, and if the contract doesn’t spell it out, it’s interpreted narrowly, limited to what’s essential for the job.
White-label adds a chain on top of that: the partner builds, the agency delivers and the client uses. To guarantee the client’s rights, the agency has to hold them first, so the agreement should state that the partner transfers to the agency (or directly to the end client) the exploitation rights over the code developed specifically for each project. The partner can keep the rights to generic, reusable components that are part of how it works, as long as that doesn’t limit the client’s ability to maintain and evolve what it received.
What matters is that it’s in writing. That it doesn’t depend on what each side remembers from a conversation 6 months ago. For the technical side, go through the technical clauses your development contract should include.
The same goes for confidentiality. The partner gets access to the end client’s business, systems and data, and that calls for an explicit commitment that protects both the agency and the client. Not out of distrust, but out of professionalism.
If the partner will handle personal data (a customer database, an online store’s orders, contact form submissions), a generic confidentiality clause isn’t enough. The GDPR requires a data processing agreement that sets out what data is processed, for what purpose and with what security measures. In practice, the partner usually acts as the agency’s sub-processor, and the agency needs the client’s authorization to use it, all of which also has to be in writing.
And there’s one clause that’s almost mandatory in white-label: non-solicitation. The partner agrees not to offer its services directly to the agency’s clients during the collaboration and for a reasonable period afterward. Without it, the agency is sharing its client list with no protection at all.
What happens when something goes wrong
An agreement that doesn’t define what happens when things don’t go as planned is an incomplete agreement.
The most common problems in white-label collaborations come down to 3: missed deadlines, delivered work that isn’t up to standard, and scope changes nobody managed properly whose cost has to be absorbed somewhere.
For each of these scenarios, and for one nobody wants to picture at the start, the agreement should have a clear answer before they happen.
Deadlines. What’s the process when a deadline is going to be missed? How much notice is given? If the delay affects delivery, who faces the end client and how is the cost shared? A partner who warns you early is a partner you can work with. One who warns you the day before is a structural problem.
Quality. What’s the review process before delivery to the client? Who confirms the work meets the agreed requirements? For how long are post-delivery fixes covered at no extra cost? A minimal quality control process prevents a lot of difficult conversations.
Scope changes. On almost every project, the client ends up asking for something that wasn’t in the original brief. The question isn’t whether it will happen, but how it’s handled when it does. Who assesses it? How is it quoted? Who tells the client about the impact on timing and cost? An agreed protocol saves more arguments than you’d think.
Ending the collaboration. Nobody starts a relationship thinking about how it ends, but it pays to plan for it: notice period, handover of access, code and documentation for ongoing projects, and who maintains what’s already live. If the time comes, nobody should be left hanging, least of all the end client.
The right time to sign
The conversation about the agreement should happen before the first project, not during it.
When there’s a project on the table and a client waiting for an answer, nobody has the time or energy to negotiate the details of a long-term collaboration. You agree on the bare minimum to get started, not on what’s best for a lasting relationship.
The ideal moment is when there’s mutual interest but no urgency yet. A 2-hour meeting to go over how each side would work, what each expects from the other, where the limits are and what the expectations are. That clarity shows in every project that follows.
The best white-label agreements aren’t the longest ones, but the ones that 2 parties who want to work together for a long time have thought through calmly.
The document is the result of that conversation. Not the other way around.
At Baqueiro, we work with agencies under white-label agreements defined from the very first project. If you’d like to see how a collaboration with your agency could work, let’s start with a no-strings conversation.