XR programmes rarely fail at the build.
When an immersive programme is quietly shelved, the post-mortem usually blames the technology. That is almost never what happened. In our experience the actual causes are three, and none of them are engineering:
- Nobody wrote down what success looked like. The pilot ran, people enjoyed it, and there was no agreed number that would have unlocked the next round of funding. So it did not get one.
- The people whose approval was required never experienced it. A headset in one office, a rota, a facilitator. Six months later the executive sponsor has still only seen a video.
- The first build was the full build. The organisation committed to a platform before it had evidence, discovered a wrong assumption at month five, and had no cheap way to change course.
The question is never “is XR impressive”. It is “what would have to be true for this to be worth funding”, and that is answerable long before the full build.
Every one of those is a process failure, and all three are avoidable for a few thousand pounds.
The ladder, with real figures.
Four stages. Each one exists to buy information that makes the next decision cheaper.
| Stage | Buys you | Our published figure |
|---|---|---|
| Discovery | Feasibility, an architecture outline, a roadmap and a budget estimate | £495 Idea Validation Sprint |
| Prototype | One question answered, with a link people can open | From £2,800 |
| Pilot | Real users, real data, a defensible result | From £9,000 |
| Platform | A system other people operate and own | From £28,000, support from £1,500 a month |
Those are our figures for the software. A programme total reaches six figures elsewhere — creating the 3D content, integrating with enterprise systems, rolling out across sites, buying and managing devices, and supporting it for years. That is the number the business case has to justify, which is exactly why the first three rungs are worth climbing deliberately.
The discovery stage is the one people skip, and it has the best return of the four. Ninety minutes, a feasibility review and a budget estimate for £495 either de-risks the £28,000 decision or prevents it. We have ended that session by recommending against building more than once.
Write the kill criteria before you build.
This is the single highest-leverage thing in the article, and it takes an afternoon.
Before commissioning anything, get the sponsor to complete these four sentences in writing:
- “This is worth continuing if …” — a threshold, with a number.
- “We stop if …” — the same, from the other direction.
- “The decision this supports is …” — a business decision, not a feature.
- “The person who has to be convinced is …” — a named individual.
Two things happen when you do this. The first is that the prototype gets much smaller, because most of what was specified turns out not to bear on the decision. The second is that a negative result becomes a legitimate outcome rather than a career risk — which is the only condition under which anyone will report one honestly.
A kill criterion is not pessimism. It is what makes the positive result mean something, because a test that could not have failed has not demonstrated anything.
The four questions a prototype should answer.
A prototype is not a small version of the product. It is an instrument for answering questions you cannot answer any other way. There are four worth spending money on, and most projects only need one or two.
1. Does the content survive contact with full scale? Things that read beautifully on a monitor frequently do not at one-to-one in a headset — proportions look wrong, detail that mattered disappears, detail that did not becomes distracting. This is unknowable from a render and cheap to test.
2. Will the people who matter actually open it? The most under-tested assumption in enterprise XR. Send the link to eight real stakeholders with no explanation and count how many open it, on what, and how far they get. This one question has cancelled more of our clients’ projects than every technical finding combined — profitably, before the money was spent.
3. Is the interaction obvious without a person standing there? Demos are facilitated. Products are not. If the prototype needs narration, the product will need training, and training is a cost nobody put in the business case.
4. Does the 3D earn its place? The hard one. Would a good video, an interactive 2D diagram or a well-built configurator have produced the same outcome for a tenth of the cost? Sometimes the honest answer is yes, and finding that out for £2,800 is a good day’s work.
Why WebXR is the right validation technology.
You can validate an XR idea natively. It is just slower and more expensive, and the delay is usually where the momentum dies.
Distribution is the whole point at this stage. Validation depends on getting the thing in front of people who are busy, sceptical and not in your building. A link does that. A store listing, a managed deployment or a sideloading instruction does not, and every step you add between the sponsor and the experience cuts your sample size.
Iteration speed is the second point. During validation you will change your mind, twice. On the web that is a deploy. On a native pilot it is a release cycle, and by the third one the quarter is over.
The flat view is a feature, not a compromise. Most of the people whose opinion decides this do not have a headset and will not get one for a trial. A browser build serves them the same product on a laptop. In a native pilot they see a video of someone else using it, which measures nothing.
The trade-off is real and worth stating: a WebXR prototype cannot tell you how the final native experience will feel if the final product is native and heavy. What it can tell you is whether the idea, the content and the audience work — which is what stops the programme being wrong. Then build the production version on whatever architecture the answer demands.
Measuring a pilot so the result is defensible.
The pilot stage is where business cases are won and lost, and it is usually measured badly — session counts, time in headset, a satisfaction survey. None of those survive a finance review, because none of them are money.
Measure against the thing being replaced. That means capturing a baseline before the pilot, which is the step everybody misses and cannot be recovered afterwards.
| Instead of measuring | Measure |
|---|---|
| Time spent in the experience | Time to competence, against the current method |
| Sessions completed | Errors, incidents or rework avoided |
| Positive feedback | Travel, trainer time and equipment downtime removed |
| Engagement | Sales-cycle length, or conversion at the step this touches |
| Number of headsets deployed | Cost per trained person, or per qualified lead |
Two disciplines make the result hold up. Take the baseline first, from whoever currently owns the process, and get them to agree it is fair before the pilot starts. And have a control where you can — one cohort on the existing method, one on the new one. It is less work than it sounds and it is the difference between a result and an anecdote.
If the outcome is a training programme specifically, the arithmetic has its own shape — existing course cost, trainer time, employee time, travel, consumables, equipment downtime and incident cost, divided into the programme cost to get a payback period. We have written that up separately.
A three-month sequence that works.
If you are starting from a slide and a sponsor with an unspecified budget, this is the order that produces evidence fastest.
- Week 1 — discovery. Agree the decision, the audience, the named sceptic and the kill criteria. Get a feasibility view and a budget estimate. Leave with a written scope or a written recommendation to stop.
- Weeks 2–5 — prototype. One question, one scene, a real link. Representative assets, not final ones. The flat view designed properly, because that is what most people will see.
- Week 6 — unfacilitated testing. Send the link cold. No demo, no call. Watch what happens against the criteria you wrote in week one. Report the result honestly even if it is inconvenient, and especially if it is.
- Weeks 7–12 — pilot, only if the criteria were met. Real users, baseline captured, measurement plan agreed with whoever will be asked to sign the platform business case.
- Then, and only then, the platform decision — with evidence, a realistic content estimate, and a named owner for the year after launch.
Twelve weeks and a low four-figure spend to reach a decision that would otherwise be made on instinct. The organisations that do this do not build fewer immersive systems. They build fewer that get quietly switched off.
What this means for a buyer.
Start with the business decision, audience, and evidence the project must produce. Simam Digital can turn that into a focused discovery, prototype, MVP, or production roadmap across AI applications, SaaS platforms, digital twins, real-time 3D, XR, and interactive systems.
