How to design a platform pilot your board can actually judge

Scope it to one operating company, not a country cluster. Write the exit numbers before the first commit — digitized-order share, feature lead time in days, run-cost per order, oversell rate — and get the board to sign them. Run it in coexistence with the incumbent so nothing critical rides on the pilot. Keep the code in your repositories from day one. Give it roughly twelve months. That is a pilot judged on evidence, not on a demo.

Why do most platform pilots become un-judgeable?

Because they are quietly engineered to be un-fail-able. Scope creeps from one market to a whole region so the programme looks ambitious. Success gets defined as 'we went live' rather than as a measured outcome. The pilot runs as a hard cutover, so the only signal the board receives is survival — nobody can say whether it was better, only that it did not collapse. And the code sits in a vendor's repository, which means even a good result leaves you unable to independently continue without another contract. Six months in, the honest questions — is it cheaper per order, is it faster to change, does it lie less about stock — have no agreed answers, because nobody wrote them down while there was still nothing to defend. The board ends up voting on a demo, a reference call, and a feeling. That is not a decision; it is a hostage negotiation with better slides.

What separates a pilot the board can actually judge?

Three properties: bounded scope, written criteria, and reversibility. You prove the platform in one operating company, against numbers agreed in advance, while the incumbent keeps running underneath. The public precedent for the shape is a top-3 global brewer's B2B rollout: as documented in Virto Commerce's case study, the first Singapore operating company went live in roughly two months on an MVP-first approach, and the same core was then scaled to 25+ countries and 370,000+ users. Within two years the digital channel reached 30% of operating-company revenue, and new markets later launched at about 35% of the original build cost. The transferable lesson is not the vendor or the stack — it is the sequence: prove it in one OpCo, then let a shared core carry the rest, the same way you would replace a commerce stack while it keeps running rather than in one dramatic weekend.

Which numbers should the board sign before you start?

Four, and they should be written down and signed before a single line of code exists. Each one is legible to a non-engineer and hard to game.

Set the thresholds yourself — that is the point. A board can read 'digitized-order share above 60%, feature lead time in single-digit days, run-cost per order below the incumbent's, oversell rate no worse than today.' What it cannot read is a metric invented after the results are in to explain why they were fine.

How do you design the twelve-month pilot?

The shape we run a pilot in is deliberately boring, because boring is what a board can approve. Six concrete steps:

1. Pick one mid-complexity OpCo. Not the global flagship, not the market nobody would miss. You want a real business with real order volume and normal operational mess, so the result generalizes.
2. Baseline the four numbers on the incumbent first. Measure digitized-order share, lead time, run-cost and oversell on the system you already have. No baseline, no verdict — you cannot claim 'better' against a number you never took.
3. Run in coexistence, not cutover. Put both systems on one event bus rather than a middleware translation chain, so order, stock and returnable events reach the new platform and the incumbent at once. The incumbent stays system of record — and your SAP financial core stays exactly where it is — until a metric threshold earns the switch.
4. Integrate API-first. Expose the incumbent and the pilot through clean interfaces instead of a bespoke point-to-point mess you pay to build and then pay again to unpick. Coexistence only stays cheap if the seams are standard.
5. Put the code in your repositories from the first commit. Add source escrow and a written insourcing option. If the pilot wins and you decide to run it in-house, that is a clause you already signed, not a renegotiation from a position of weakness — which is where the build-versus-buy math for 2026 actually gets decided.
6. Fix the exit review in advance. A dated review, the four signed numbers, and a named person who says go or no-go. Movable dates and soft criteria are how a pilot quietly becomes a permanent programme nobody chose.

The part that is genuinely hard, and worth saying plainly, is coexistence itself: running two systems against one event stream means reconciling drift between them, and dual-write divergence is the failure mode that will eat your evenings. Budget the reconciliation work explicitly — a daily diff of orders and stock positions across both systems — rather than discovering it in month seven when a threshold is finally in reach.

The shift worth planning around is that the pilot and the first production market are collapsing into the same twelve months. A small, AI-augmented team can now stand up a real operating company fast enough that 'let us trial it' and 'we are live in one market' stop being different phases. Boards still budgeting a year of evaluation before any code exists are spending that year to learn less than one instrumented OpCo would tell them. Write the numbers down, ship one operating company, and let the evidence do the arguing.