TL;DR: An XR proof of concept exists to answer one question before you fund the full build: can the riskiest thing this app depends on actually work, on the real headset, in the real environment? Not "will people like it" (that is a pilot) and not "what will it look like" (that is a prototype or a mockup). Pick the one or two technical unknowns that would invalidate the plan, write pass and fail criteria before anyone builds, test on the target device where the app will really be used, and treat a clear "no" as a good outcome. A well-scoped XR proof of concept is short, ugly on purpose, and ends with a decision.
Most XR projects that go badly fail at the start, quietly, when a team commits a full budget to a plan resting on an assumption nobody tested. The hand tracking will be precise enough. The anchors will hold in that warehouse. The headset will run the scene at frame rate. Each can be true or false, and you find out only by building the smallest thing that tests it.
That smallest thing is the proof of concept. Here is what it should prove, what to leave out, how to scope one so it ends in a decision, and what to ask a vendor.
Proof of concept, prototype, pilot: three different questions
These words get used interchangeably, and that is where a lot of wasted money starts. They answer different questions, so they need different scopes.
- A proof of concept asks: can it work? It tests technical feasibility on the target hardware. Its audience is the people making the build decision. It can look terrible.
- A prototype asks: how should it feel? It tests interaction and flow, often with placeholder art, so that real users can react to the experience before it is built properly. We cover the interaction side in XR interaction design.
- A pilot asks: will it work here, for these people, at this scale? It tests the experience and the operation around it with real users at a real site. That is a much bigger exercise, and we cover it in taking XR from pilot to rollout.
Running a pilot when you needed a proof of concept means paying for polish and logistics on an unproven foundation. Know which question you are asking first.
What an XR proof of concept should prove
The right scope is the one or two unknowns that would change the plan if the answer came back wrong. In XR those unknowns cluster in a few predictable places.
Tracking in the real environment
Tracking that works in a bright office can struggle in a dim corridor, a reflective lab or an outdoor site where light changes by the hour. If the app depends on anchoring content to a physical space, the proof of concept has to run in that space, or one honestly like it. Location-based AR adds GPS accuracy, compass drift and the gap between a map and the street, which is why our location-based AR work starts with on-site tests rather than desk tests.
Performance on the target device
A scene that looks fine on a development PC can fall well below the frame rate a standalone headset needs, and a dropped frame in a headset is not a cosmetic issue, it is one of the known contributors to VR motion sickness. If the app needs dense geometry, many dynamic objects or heavy effects, the proof of concept should load a representative amount of it onto the real device and measure.
Sensor and measurement validity
When a headset's sensors are the product, the proof of concept has to show that the data is good enough for the purpose. Nystag, the clinical VR eye-tracking diagnostics tool we built on the Vive Focus 3, is the clearest example from our own work: the eye tracker is not a feature there, it is the measurement. The first question in a project like that is whether the hardware can capture what the clinical workflow needs, not what the menus look like. We go deeper on that kind of project in clinical VR diagnostics.
Live data and outside services
If the experience depends on a live feed, prove the feed early. Planes XR, our location-based AR build for ARCortex, connects to OpenSky to show real flights on live maps. An app like that inherits a service outside your control, so confirm the data arrives fast enough and fails gracefully.
Multiple people in one space
In shared experiences, everyone has to see the same object in the same place, changes have to sync fast enough to feel live, and sessions must survive people joining late. MR Camera, our multiplayer mixed-reality environment where several users place and interact with 3D models in shared space, is the kind of build where that synchronization is the first thing to prove. More on the problem in mixed-reality collaboration.
Content from your real source material
If the plan assumes your CAD files, scans or floor plans can become headset-ready 3D, test a real sample, not a clean demo asset. That gap is often bigger than expected and sets a large share of the budget. Our XR 3D content pipeline guide covers why.
Interaction under real conditions
ERIS XR, the platform we built for ARCortex to help firefighters pre-plan and train, has to work for people under stress. If your users wear gloves, work one-handed or have seconds rather than minutes, test the core input under those constraints.
What a proof of concept should leave out
The discipline is in what you do not build. A proof of concept usually has no polished art, no onboarding, no settings, no account system, no analytics dashboard, one scene rather than several and one device rather than a cross-platform matrix. Anything that does not help answer the question is cost without information. Show it only to people who know what it was built to prove, because an ugly feasibility test can sink a good idea in a steering meeting.
How to scope one so it ends in a decision
A proof of concept without written success criteria tends to end in "it sort of works", which is the most expensive possible result because it decides nothing. A short brief fixes that. It needs:
- The question. One sentence. "Can the Vive Focus 3's eye tracking capture the signal our assessment needs?" is a question. "Explore eye tracking" is not.
- Pass and fail criteria, written first. Frame rate held over a session length, anchor drift within a tolerance you can name, data latency below a threshold, sync delay that still feels live. Agree on them before the build starts, so nobody moves the line afterward.
- The target device and environment. Exactly which headset, and where it will be tested. If the real environment is not available, say what stands in for it and why it is close enough.
- Who tests it. Engineers can test feasibility, but if the risk involves real users, such as clinicians, trainers or field staff, a few of them should try it.
- A timebox. A proof of concept should be short enough that its cost is small next to the full build. If it keeps growing, it has stopped being one.
- The decision it feeds. Name it in advance: go ahead as planned, change device, change approach, or stop.
If you are writing a brief for the whole project as well, our guide to writing a software project brief covers the rest.
Reading the result
There are three honest outcomes, and all three are useful.
A clear pass means the riskiest assumption held and the full build can be scoped against measured numbers instead of hopes. That makes the next estimate far more reliable, a point we make in what an XR app costs.
A clear fail means you just saved most of a budget. It often does not kill the idea. It points to a different headset, a different approach (a tablet or phone instead of a headset, for instance, or WebAR with no app at all) or a narrower scope that avoids the weak spot.
A partial result is the one to handle carefully. It works sometimes, in some conditions. Write down exactly which conditions, then decide whether the product can live inside them. If the answer depends on hoping hardware or software improves later, treat that as a fail.
What carries forward and what gets thrown away
Be honest about this before you start. Proof-of-concept code is written fast to answer a question, and much of it should be rewritten for production. What carries forward is the knowledge: measured performance, the device choice, the engine choice, the content pipeline decisions, the data integration approach and a list of the things that did not work. That knowledge is what you paid for.
Watch for a proof of concept that quietly becomes the product because it was already running. If a vendor plans to build on it, get the path to production standard in writing.
Cost and contract shape
We will not quote a typical number, because it depends entirely on the question. What we can say is the shape: a proof of concept is the smallest piece of the project, priced on its own, and it should not commit you to the full build.
Because the scope is narrow and the outcome is a decision, a proof of concept often suits a fixed price, while the build that follows may not. We explain the trade-off in fixed price vs time and materials.
Questions to ask before you commission an XR proof of concept
- What exactly is this proof of concept testing, in one sentence?
- What are the pass and fail criteria, and can we agree on them before work starts?
- Will it run on the exact headset and in an environment like ours?
- What will be thrown away afterward, and what will carry into the full build?
- Who owns the code, the findings and any test data at the end?
- Is the proof of concept priced and contracted separately from the full build?
Where we fit
In every XR build we have shipped, from ERIS XR to Nystag to MR Camera, the hardest part was the thing worth proving first. If your idea rests on an untested assumption, a short proof of concept is usually the cheapest way to find out whether it holds. For the device side of that decision, see which XR headset to build for.
Have an XR idea that depends on something you have not proven yet? Book a demo and we will help you name the riskiest assumption and scope a proof of concept around it. See our XR work: ERIS XR and Planes XR for ARCortex, Nystag clinical VR eye-tracking on the Vive Focus 3, and MR Camera shared mixed reality.