Agencies · 4 min

Hiring a white-label development partner: what agencies check first

For brand and design agencies in Toronto and Québec: how to vet a build partner before a client project depends on them, the terms that protect your margin and your client, and the first job to give them.

In short
  • Vet a partner with a small paid job, not a portfolio. Judge the communication and the delivery on something a bad week can absorb.
  • Four terms before any client work: fixed price from a written scope, agreed lead times, a non-solicitation, and code that belongs to your client.
  • The partner should be invisible by default and on your client calls when useful, with a working demo every week in your channels.
  • Match the stack to what your team can maintain, and ask for both languages if the work has to land in Québec or in English Canada.

An agency wins a project it cannot staff: a client portal, an integration, a product feature, an AI request nobody on the bench can ship past a demo. The answer is a build partner working under your brand. The risk is that the partner becomes the project’s weakest point, on a deadline, in front of your client. Here is what agencies who have done this many times check first, and the order they check it in.

Start with a small paid job

Portfolios are how partners sell. They are not how agencies vet. Case studies show finished work, chosen by the partner, with the difficult weeks edited out. What you need to know is how the person behaves under a scope, a deadline and your client’s changes, and the only way to learn it is a small paid job.

Pick something real but contained: a landing page, one feature, a single integration. Fixed price, agreed date. Judge three things while it runs: whether the scope was questioned intelligently before work started, whether you heard from them before you had to ask, and whether the delivery matched the date. A bad outcome costs you a week. A good one gives you a partner for years.

Four terms before any client work

Agree these in writing before the first job, and keep them on every job after.

  1. A fixed price from a written scope. An hourly meter moves the risk of being wrong onto your margin. A fixed price from a scope you both signed moves it back to the builder. If a partner will only quote hourly, keep looking.
  2. Agreed lead times. How long from a request to a start, and what happens when they are at capacity. The right answer to “can you take this next week” is sometimes no, with a date. A partner who says yes to everything is the one who drops something.
  3. A non-solicitation. Your client stays yours, in writing, before you have to ask. A partner who offers it unprompted understands what the relationship runs on.
  4. Ownership. The repository, the infrastructure and the accounts belong to your client from day one, under your name. Nothing the project depends on should live only with the partner.

An NDA usually sits alongside these. It matters less than the non-solicitation. Most partners will sign one; fewer will offer the second.

How the work should run

The day-to-day is where agencies get burned, and it is easy to specify.

  • Invisible by default. Files, staging environments and repositories carry your name and your templates. The client sees your agency.
  • On your calls when useful. When a technical question needs a straight answer, the partner joins as part of your team, then disappears again.
  • A working demo every week, in your channels. Not a status report. The software, running, in the Slack or the Basecamp you already use with the client. If you cannot see it working, it is not working.
  • The same timezone, and a person. Overnight handoffs turn a one-hour question into a two-day delay. A partner you can meet in person, in the city where the client is, removes a category of problems.

Match the stack

The right technology is the one your team, or your client’s team, can maintain after launch. A marketing site the client will edit belongs in a tool like Webflow. A product with accounts, data and workflows belongs in code, on widely used stacks a future developer will recognise. Ask the partner what they build in and what they refuse to build in. “Anything” is the wrong answer; it means learning on your deadline.

Ask for both languages

Toronto work that has to land in Québec, or Québec work headed for English Canada, fails at the French more often than at the code. A translated interface, English error messages, transactional emails in the wrong language. If the project touches both markets, ask whether the partner writes both languages natively and whether they build them in from the first commit. Retrofitting French is a rebuild, and it shows up on your margin. We wrote about why in A French website is not a translated website.

The checklist

Before the first client project, you should be able to answer yes to all of these.

  • We have done one small paid job together, and it shipped on the date.
  • The price is fixed, from a scope we both signed.
  • Lead times are agreed, and we know what happens at capacity.
  • A non-solicitation is in writing.
  • Our client owns the code and the accounts.
  • We see working software weekly, in our channels.
  • The stack is one our client can live with after launch.
  • Both languages are covered if the work needs them.

This is the arrangement we work under with agencies in Toronto and Québec. If you have a project you are stuck staffing, describe it in two sentences and you will have a fixed quote, a date, or a no with a reason within one business day.

Start with a Discovery.

Two sentences start it. Here is what happens next.

  1. Now You write, in English or in French: what the business does and what stalls today.
  2. Within one business day A written reply from Nicolas, the person who would build the product.
  3. This week A short call. If it’s not a fit, we say so, with where to look instead.
  4. One to two weeks The Discovery: a written spec, a fixed quote, a date. Yours, whatever you decide.