Written for the product builder at a health-tech vendor (Head of Product persona) who has lived or is anticipating pilot purgatory, with the outcome story led and the integration mechanics kept underneath it, as the persona research recommends. No customer names or specific vendor examples; the pattern is described generically enough that any reader mid-pilot will recognise their own situation in it.
A health-tech vendor runs a pilot at one Trust. It goes well: clinicians like it, the outcome data is genuinely good, the Trust wants to keep it. Eighteen months later, that Trust still has it, and nobody else does. The product didn't fail. It's stuck in what everyone in NHS-facing health-tech quietly calls pilot purgatory, and the sales team is having conversations about pipeline while the actual blocker sits somewhere in engineering.
This is one of the most common and most avoidable failure modes in NHS-facing health tech, and it's avoidable because the cause is usually visible before the pilot ever launches, if anyone looks in the right place.
In brief
Pilots at NHS Trusts succeed on clinical merit and stall on integration architecture, and the two are almost never evaluated at the same time. A pilot that was quietly hand-built around one Trust's specific systems, data quirks and workflows will not survive contact with a second Trust's different EPR, different local coding conventions, and different IT governance process without substantial rework, which looks to leadership exactly like starting over. The fix isn't a better sales pitch for Trust two; it's building the pilot itself on a configurable integration layer from day one, so that what changes between Trust one and Trust ten is configuration, not a rebuilt integration.
The pilot that never became a rollout
The pattern is consistent enough to describe generically. A vendor's team, moving fast to prove clinical value, builds direct, often hard-coded connections to the pilot Trust's specific systems: a particular EPR version, a particular way that Trust represents a code, a workflow shaped around how that Trust's clinicians happen to work. The pilot succeeds, because it was built, quite reasonably, to succeed at exactly this Trust.
Then a second Trust expresses interest, and the integration that felt like a solved problem turns out to be Trust-one-specific in a dozen small ways nobody flagged as a decision at the time: a different EPR, differently structured local codes, a different IT governance process, a rostering system that doesn't behave the same way. What should have been "deploy the same product again" becomes "substantially rebuild the integration," and from a leadership seat, at either the vendor or the commissioning body, that looks indistinguishable from the product simply not being ready.
Why pilots succeed and rollouts stall
he uncomfortable truth is that pilot success and rollout readiness are measuring different things, and a good pilot outcome tells you almost nothing about the second. A pilot proves clinical and operational value at one site under one set of conditions. Scaling requires the integration to tolerate variation across sites it was never built against, and those are genuinely separate engineering problems. A team focused entirely on proving clinical value, which is exactly what a pilot should prioritise, has every incentive to take integration shortcuts that make the pilot land faster and every reason not to notice those shortcuts are the ones that will hurt later.
The tell that shows up before Trust two
There's a diagnostic question worth asking of any pilot integration before it's declared a success: if the next Trust had a different EPR and different local coding conventions, what in this integration would need to change? If the honest answer touches core logic, hard-coded field mappings, or assumptions baked into the workflow itself, that's pilot purgatory being built in real time, well before anyone's noticed a stall. If the answer is "a new configuration, not new code," the integration was built to scale from the start, and that distinction is knowable at pilot design time, not just discovered painfully at Trust two.
What changes in the build, not the pitch
The fix for pilot purgatory lives in engineering decisions made before or during the pilot, not in a better story told to the second Trust. Concretely, that means building on a workflow layer where site-specific detail, extract layouts, local code mappings, EPR-specific quirks, lives in configuration rather than in code paths unique to the pilot Trust. It means treating terminology as infrastructure from the start, so a different Trust's local coding conventions are a mapping to add rather than a rewrite to undertake. And it means designing the integration's validation and exception handling generically from day one, so a second Trust's edge cases surface as configuration gaps to fill rather than production incidents to firefight.
None of this is a claim that pilots should be slower or more heavily engineered up front; a pilot still needs to move fast to prove clinical value. It's a claim about where the corners get cut: cutting them in the workflow-specific logic is fine, cutting them in the underlying integration architecture is what builds pilot purgatory in.
The outcome story, with the integration underneath
The commercial lesson worth taking from this is subtle but important: a vendor that can credibly tell a prospective second, third and tenth Trust that their integration is a configuration exercise, not a rebuild, is making a genuinely different, and more believable, promise in procurement than one still recovering from a difficult second deployment. That's not a claim to make in a pitch deck; it's a claim that has to already be true in the architecture by the time anyone asks the question, which is exactly why it needs deciding at pilot design time rather than retrofitted after the stall becomes visible.
The bottom line
Pilot purgatory looks like a sales or adoption problem from the outside, and it's almost always an integration architecture decision made, invisibly, during the pilot build. The fix costs more attention at the start and saves far more than that at Trust two. Before the next pilot launches, ask the diagnostic question directly: if the next site had a different EPR and different local codes, what would have to change? If the honest answer is "the code," that's the actual roadmap item, and it's cheaper to fix now than after the second Trust has already stalled.
