When Should a CRO Agency Outsource Experiment Development?

Five signals that development is your bottleneck, the arithmetic of hiring versus outsourcing, and how to protect the client relationship.

Outsource experiment development when your delivery is capped by build capacity rather than by ideas, and when the volume is not yet steady enough to justify a salary. The clearest signal is a retainer sold at four experiments a month that consistently ships two, strategy and design can produce the four, and the build cannot. At that point you are already paying for the gap, in underdelivery and in renewal risk.

The harder question is not whether to outsource but what to outsource, and there is a clean answer to that.

Five signals it is time

1. Your backlog is older than your research

If hypotheses from a study you delivered last quarter are still unbuilt, the research is decaying on the shelf. The site has changed, the seasonality has changed, and the prioritisation was made against conditions that no longer hold. Development capacity is not the only cost of this; the research you already paid for is being written off.

2. A specialist platform arrives once a quarter

An Adobe Target build, or a single-page-application experiment, or a Shopify cart change. Not frequent enough to hire for, too consequential to improvise on. This is the single most common reason agencies reach for outside capacity, and the easiest to justify.

3. Your one developer is a single point of failure

One person holds all the platform knowledge, all the client context and all the launch windows. That is fine until they take annual leave, at which point your delivery stops. Outside capacity is cheap insurance long before it is a growth strategy.

4. Volume swings by more than a factor of two

If your monthly build load ranges from two experiments to eleven, a fixed hire is wrong in both directions: idle at the bottom, overwhelmed at the top. Variable capacity matches variable demand, which is the entire argument.

5. QA is the thing being skipped

When capacity is tight, QA is what gets cut, because it is the least visible line in the delivery. This is the most expensive possible thing to cut, it converts experiments into noise, and it is a reliable indicator that the team is over capacity rather than under-disciplined.

The arithmetic, without invented numbers

Use your own figures. You need three.

• Your monthly experiment build load, honestly averaged over the last six months, and its range.
• The all-in monthly cost of a developer to you: salary, employment costs, tooling, recruitment amortised, and management time.
• The revenue you lose from underdelivery: retainers reduced, renewals lost, and work you declined because you could not build it.

A hire is the right answer when your load’s lower bound would keep that person productive. If the lower bound leaves them idle for a meaningful part of the month, you are buying capacity you cannot use, and variable capacity is cheaper even at a higher notional rate. The trap is comparing an hourly rate to an hourly salary equivalent, which ignores both idle time and the recruitment lead time for a thin specialism.

The question is not "which is cheaper per hour". It is "which is cheaper per experiment I actually ship, including the ones I did not".

What to outsource, and what never to

The dividing line is whether the work is where your value is visible to the client.

Sensible to outsource

• Variation build and QA. Highly specifiable, verifiable against an objective standard, and invisible to the client when done well.
• Platform-specific implementation on tools you use rarely.
• Overflow during a spike, so you do not have to decline work.
• Independent QA on experiments your own team built, a pass by someone who did not write the code catches what the author cannot see.
• Rolling winners into a client codebase, which is often the least interesting work you have and the easiest to hand over.

Keep in-house

• The client relationship and the account. Always.
• Research, hypothesis generation and prioritisation. This is what you are actually selling.
• The read-out and the recommendation. Someone who has not sat in the client’s strategy meetings should not be interpreting the result.
• Anything requiring deep, accumulated knowledge of a proprietary system, where the handover cost exceeds the build.

How outsourcing goes wrong

The failure modes are predictable, which means they are avoidable.

• Briefs written for someone with your context. An external developer does not know the client’s history; a brief that assumes it produces the wrong build, on time.
• No named owner on your side. If nobody internally owns the relationship, work arrives correct and unintegrated.
• Outsourcing the read-out along with the build. The one thing the client is paying you for.
• Discovering the confidentiality terms after the first project. Settle NDA, access and client contact before any brief is shared.
• Choosing on rate. The cheapest quote is usually the one with QA quietly removed, and you will pay for that in a result you cannot defend.

Protecting the client relationship

Most agencies’ real objection to outsourcing is not quality; it is exposure. A subcontractor turning up in a client’s Slack, or reappearing later as a competitor, is a worse outcome than an unshipped experiment. That is a contractual and operational problem, and it should be settled once rather than negotiated per project.

• Your NDA, signed before any brief is shared, not theirs.
• A stated position on client contact: none by default, and on your terms if you want it.
• A written non-solicitation covering your clients.
• Access through seats you control and can revoke.
• QA evidence written client-ready, in your voice, so it can be forwarded without editing.

That operating model, what happens, in what order, and who talks to whom, is described in how white-label CRO development works.

A sensible way to start

Do not start with a retainer, and do not start with your most sensitive account. Give one real experiment from your backlog to an outside developer and watch the process: whether they ask questions before writing code, whether they flag something in the brief you had missed, and whether the QA evidence arrives unprompted and forwardable.

One build tells you what you need to know. If it goes well, the natural next step is reserved capacity; if the volume stays unpredictable, allocated hours are the better shape. Both are described under white-label CRO development.