White-label software development: how agencies subcontract engineering work

What white-label development means

White-label software development means a partner does engineering work, such as a web or mobile application, that you deliver to your own client under your name. An agency, a consultancy or a software house uses it to add capacity or skills without hiring.

White label

A partner builds, and you present the result to your client as your own work. White-label software is software made by one company and sold or delivered under another's name.

Subcontracting

You are the main contractor for your client, and you pay another company to do part of the work.

Staff augmentation

Engineers from another company join your team and work under your direction.

Subcontractor and freelancer

A subcontractor is a company, with a team, a contract and cover when a person is away. A freelancer is one person.

When it fits, and when it does not

It helps when the work is yours to sell and the engineering is the part you cannot staff.

It fits when

• You win more work than your team can build.
• You need a skill for one project, such as mobile, payments or data.
• You want capacity for a peak, and to release it afterwards.
• You have people who can review the work and talk to the client.

It does not fit when

• Nobody on your side could tell good work from bad.
• Your client's contract forbids subcontracting.
• The work is so sensitive that nobody outside your company may see it.
• You hope that the partner will also manage the client.

Check your own contract first

What you may pass on depends on what you promised. This is general information, not legal advice, so ask a lawyer who knows the law that applies.

• Does your client's agreement allow subcontracting, or does it need the client's consent or notice in advance?
• Which duties of confidentiality and data protection do you owe, and do they have to pass down to the partner?
• Who owns what you deliver, and how does ownership pass from the partner to you and from you to the client?
• What liability limits and insurance does the client expect?
• Does the client expect named people, and what happens if one is replaced?

Ways to work with a white-label partner

Choose the way that matches how much of the work you want to control.

Keep quality in your hands

The client holds you responsible for what the partner builds.

• Keep the repository, the cloud accounts and the deployment in your own organisation.
• Agree a shared definition of done, including tests and a review.
• Review code and demonstrations yourself, or with an engineer you trust, before the client sees them.
• Use your own tracker and tools, so that the history stays with you.
• Run the security checks that you would run on your own team's work.

Confidentiality, ownership and your client relationship

The partner stands between you and your client's trust. Protect both.

• Confidentiality: the partner is bound to at least what you owe your client, and so is each person who works on the project.
• Ownership: the partner assigns its rights to you, and you pass them on as your own contract says. The contract checklist lists the points.
• Contact with the client: agree who may talk to the client, and whether the partner may be named.
• Non-solicitation: whether the partner may work for your client directly, during the contract and after it. Ask your lawyer how such a clause works under the law that applies.
• Names and tools: whose email addresses, chat spaces and documents the partner's people use on your client's project.

Roles and communication

Most trouble starts as a misunderstanding about who may say what.

• One point of contact on each side.
• A shared calendar, and the hours you share.
• A weekly demonstration of working software.
• A written route for raising a problem, and who decides.
• Clear rules on who may promise what to the client.

Start small

Test the partner on your own client's work before you depend on it.

1. Pick a small, low-risk piece of client work

   Something that can be finished, checked and shown to the client, with little harm if it goes wrong.

2. Agree the brief, the review and the date

   Write down what good looks like and who will review it.

3. Pay for it and judge it

   Judge the code, the communication and how problems were raised.

4. Raise the volume only after it works

   Add work and people in steps, and keep reviewing as you grow.

Red flags

Any one of these is a reason to ask more questions.

• A partner who will not sign confidentiality that matches yours.
• A partner who wants to deal with your client directly.
• No way for you to see the code before the client does.
• The partner holds the repository or the accounts.
• You cannot meet the people who will do the work.
• A partner who never says no.

Keep reading

• Dedicated development teams: Engineers who work on your product as part of your team, for as long as you need them.
• How to choose a software outsourcing partner: a due diligence checklist: A due diligence checklist for choosing a software outsourcing partner: what to ask, what proof to see, how to run a paid pilot and which red flags to act on.
• Software outsourcing contract checklist: IP, data, payment and exit: A plain checklist of what a software outsourcing contract should settle: ownership, confidentiality, data protection, acceptance, payment, changes and exit.
• Dedicated development team, freelancers or agency: how to choose: Dedicated team, staff augmentation, freelancers or a project agency: how each works, when it fits, what to ask and how to keep control of the work.
• Talk to us about your project

Common questions