If you meant Contract Research Organization, the pharmaceutical kind, this is the wrong tab: nothing here involves a clinical trial. In marketing, CRO is conversion rate optimization, and CRO development is the half of it that never makes the deck. It is the engineering that turns a hypothesis into something a real visitor experiences, and into a number you are allowed to believe.
Strategy gets the attention. Research, psychology, prioritisation frameworks, the workshop with the sticky notes. All of it necessary, and none of it worth anything until somebody writes the code, wires the tracking and proves the variation renders correctly on an iPhone. Across 1640+ tests, the difference between a programme that compounds and one that quietly stops has almost never been the quality of the ideas.
So this is what the work actually involves, why it is a distinct skill rather than front-end development with a different job title, and how teams resource it. Most of it is our own A/B test development practice, written down.
What CRO development actually covers
CRO development sits where front-end engineering, experimentation tooling and analytics overlap. The job is not to close tickets. It is to produce changes whose effect on revenue per visitor can be measured, and measurements nobody has to caveat.
In practice it covers five things, and most teams are genuinely competent at one or two of them.
- A/B test development. Coding control against variation in Optimizely, VWO, Convert, AB Tasty or Kameleoon, or directly in your own stack when the change is too deep for the browser to reach.
- Winner implementation. Moving a validated change out of the testing tool and into the codebase properly, so the win does not arrive with a permanent JavaScript tax attached to it.
- Performance engineering. Page speed and Core Web Vitals work, because a slow template depresses conversion before design gets a chance to affect it either way.
- Tracking and analytics implementation. Events, revenue goals, testing-tool integrations, and the validation step that proves the numbers arriving are the numbers that actually happened.
- Platform work. Shopify theme and app engineering, WordPress and WooCommerce builds, headless storefronts, each with its own catalogue of things that will bite you.
The distinction from ordinary web development is what the output is measured in. Every build either gets validated by an experiment or implements something an experiment already validated. This guide assumes you know what a split test is and why randomisation does the work; if not, start there, because everything below sits on top of it.
Why it is not just front-end development
A competent front-end developer is not automatically a competent CRO developer, and the gap is not talent. It is that five specific things are true of experiment code and true of almost nothing else a developer builds.
- Test code runs on top of live sites, inside somebody else’s tool. Injecting JavaScript into an unfamiliar codebase through a third-party editor, without breaking the page, is its own craft.
- Flicker destroys results. If a visitor can see the original before the variation renders, the test measures the delay rather than the idea, and the variation loses for a reason that has nothing to do with the hypothesis.
- Tracking bugs are silent. A purchase event that fires twice throws no error. It just makes a losing variation look like a winner, and it carries on doing that until somebody thinks to check.
- Experiments are temporary and decisions are permanent. Test code has to be quick to build, safe to run and clean to remove, which is a different trade-off from production feature work.
- The statistics constrain the build. If a page cannot produce enough traffic to detect the effect you expect, the right move is to say so rather than to build it beautifully.
This is why the our-developers-can-handle-it approach stalls so reliably. Product engineers can build tests. But experiments lose the sprint-priority argument to features every time, and the specialist details get learned the expensive way, one corrupted dataset at a time.
Where development sits in the cycle
Eight steps, and the order is not decoration. Development owns four of them outright and has an opinion worth hearing on two more.
- Research and hypothesis. Strategy owns this. Analytics, recordings and customer feedback surface the friction, and the backlog gets prioritised against it.
- Feasibility and scoping. Development gets its first say: client-side or server-side, what it costs, and whether the page can produce a readable result at all.
- Design. Variation mockups grounded in patterns that have already survived contact with real traffic.
- Build. The variation coded, the tracking wired, the performance budget enforced rather than aspired to.
- QA. Cross-browser, cross-device, and tracking validated. Documented, not vibes.
- Launch and monitor. Allocation, targeting, and somebody actually watching the first forty-eight hours.
- Analysis and verdict. Significance, then segments, then the metrics you were not hoping to move.
- Winner implementation. Back to development, permanently, and out of the testing tool.
Step five is where the money is lost. QA on an experiment is not a glance at the page in Chrome: it is a matrix, and the one cell nobody checked is where the Safari bug lives that quietly invalidated six weeks of data. The cost is never the bug. It is the decision made on top of it.
Feasibility is not only a technical question either. The second thing to establish at scoping is whether the page has the traffic to detect it, and the honest answer is often no. A developer who tells you that before building is worth more than one who builds it beautifully and lets you discover the result is unreadable eleven days later.
The builds that move revenue per visitor
Product pages are the highest-traffic template on most stores, and the one where mobile above-the-fold hierarchy decides the outcome. Review placement, gallery behaviour, sticky add-to-cart, and where delivery and returns information sits relative to the button. Small structural changes, disproportionate effects.
Cart and checkout are small builds with outsized effects, and the riskiest place on the store to ship anything unvalidated. Cart drawer against cart page, trust signals near payment, express-pay placement, field reduction, guest checkout. Every one of them is worth testing and not one of them is worth guessing.
Collection and search work is where store-specific results are most obvious. Filter behaviour on mobile, sort defaults, how much information a product card carries. Large catalogues and small catalogues respond in opposite directions, which is the entire argument for testing rather than copying.
Speed is the unglamorous compounding asset. Theme weight and third-party scripts depress every page at once, and cleaning them up improves the accuracy of every test that follows, which is a different kind of return from a layout win and a more durable one.
Personalisation and targeting come last, not first. Returning-visitor experiences, geography-aware delivery messaging, audience-specific offers: all genuinely powerful, and all a way of multiplying a fundamental you have not validated yet if you reach for them early.
In-house, freelance, or a build partner
In-house makes sense at sustained velocity. If you are genuinely running fifteen or more tests a month, a dedicated developer and an analyst pay for themselves and the feedback loop gets shorter than any external arrangement can manage. Below that you are paying fixed salaries for spiky work, and the developer spends the quiet months on feature tickets; the full cost arithmetic is worth running before either commitment.
Freelancers work for occasional builds when you already own strategy, QA and analysis. What you are renting is hands rather than a system, which is fine as long as you know that is the trade. It stops working the moment the freelancer is also the only person checking their own work.
A build partner fits most DTC and mid-market brands: parallel capacity, documented QA, the statistics included in the conversation, and no hiring risk. If you are buying this capacity as an agency rather than as a brand, the questions are different ones and we have written those up separately.
Whichever route you take, four filters remove most of the market: documented QA you can actually read, demonstrable anti-flicker competence, tracking validation as a named step rather than an assumption, and code you own in a repository you control. Ask for evidence of all four before the rate conversation, not after it.
What the market charges for it
These are what we see quoted, not what we charge, and they move with scope, seniority and time zone. Individual client-side test builds run somewhere between £150 and £900 depending on how much of the page moves and how hostile the theme is. Server-side and checkout work sits above that range.
Standing build capacity alongside your own strategist tends to be quoted between £2,500 and £6,500 a month. Full-service arrangements, where strategy, build and analysis all sit outside, run from around £4,000 to £12,000. A retainer looks cheaper per build than per-test pricing because reserved capacity removes the per-brief scoping overhead, not because the work is any lighter.
Treat any quote that arrives without a feasibility opinion as incomplete. The number matters less than whether the person producing it has told you which of your ideas is not worth building. Cheap builds of unreadable tests are the most expensive thing in this market.
The mistakes that show up in every audit
None of these announce themselves, which is what makes them expensive, and most sit alongside the other ways a programme invalidates itself before anybody launches anything.
- Shipping a redesign without testing it. The costliest habit in ecommerce and the easiest to stop. Validate on half your traffic before committing all of it.
- Leaving winners running in the testing tool. Every one left there is permanent JavaScript weight on every page, and it will break eventually, usually during a theme update.
- Treating QA as a glance. Each unfound browser bug is a corrupted dataset, and corrupted datasets produce confident decisions.
- Building tests on pages without traffic. A perfect implementation of an unreadable experiment is money spent on nothing at all.
- Optimising design while ignoring speed. Layout work on a slow template is measured through the load time, so you are testing two things and can attribute neither.
- Keeping no archive. Undocumented experiments guarantee you will pay to learn the same lesson again in eighteen months, usually from a different agency.
Where a stalled programme restarts
Almost every stalled programme we are asked to look at has the same shape. The strategy is fine. The backlog is full. What has failed is throughput: tests take four weeks to build, half of them come back with QA problems, and nobody trusts the tracking enough to act on a close result.
That is a development problem wearing a strategy problem’s clothes, and it is fixable without changing a single hypothesis. If your programme is producing tests but not decisions, get in touch and we will look at the build side with you.
