The experience is the easy part.
XR pilots rarely end because the software was bad. They end on the surface around the software: a session too long for the rota it has to fit, onboarding that eats the slot, headsets nobody charged, no plan for cleaning between two people, and no measurement against the video or the mannequin it was supposed to improve on. Six months later the headsets are in a cupboard and the champion has changed roles.
So we design the deployment first — session length, first-time onboarding, the comfort floor, tracking-loss recovery, hygiene, charging and the measure — and the experience as one part of it. The same discipline is the fastest way to discover that the honest answer is a browser rather than a headset, and a fair share of our first engagements end exactly there.
We build a platform that turns standard medical images into photo-realistic, interactive 3-D patients for surgical preparation and VR training, for a Silicon Valley startup. It is training and rehearsal software: not a medical device, not clinically validated, and not cleared by any regulator.
The brain–computer work is a Fluvius R&D prototype, and it is labelled that way every time it appears here: an EMOTIV interface paired with Magic Leap 3 AR glasses, built as a WebXR experience with an offline fallback, plus TheCap — our own smartcap concept.
No case page on this site records a managed headset fleet we have run for a client. The deployment argument below is a design position, argued from first principles and adjacent field work, and it is not dressed as a track record. There are no learning-outcome, retention or comfort figures anywhere on this page either — none has been cleared.
30 minutes, working session. Tell us what people should be able to do afterwards, who they are and how long you get with them. You leave with a one-page read either way, and nobody follows up more than once.
Six ways an XR pilot ends, and none of them is the code
If you have run one before, you will recognise the ending you got. If you are about to fund one, these are the six things to decide before the build rather than after it.
It is in a cupboard
Six headsets, bought with real enthusiasm, used properly on demo day. Nobody was given charging, cleaning or scheduling as part of their job, the champion moved to another role, and the second person who tried it found a flat battery. That is the most common ending in this category by a wide margin, and it is an operations failure rather than a technology one.
Everyone loved it for four minutes
Which tells you nothing about a thirty-minute session, nothing about the second session next week, and nothing about the person who felt unwell at minute eight and did not mention it. Four minutes measures novelty. The number worth having is whether the tenth user, in week four, still prefers it to what they had.
Onboarding ate the session
A first-time user needs the headset adjusted, the interpupillary distance set, the controllers explained and the interface introduced before any learning starts. In a twenty-minute slot that is most of the slot — and it is the single easiest thing to design away, once somebody has actually timed it with a novice rather than with the team that built it.
Tracking went, and so did the session
Blank walls, changing daylight, a reflective floor, a room rearranged since the guardian was drawn. It re-localises somewhere wrong, the user has no idea what happened, and there is no path back except taking the headset off. Tracking loss is not an edge case in a real building; it is a Tuesday, and the recovery path is a design deliverable.
Nobody measured anything
The pilot was judged on enthusiasm in the room. There was no comparison against the video, the mannequin or the classroom session it was meant to improve on, so the renewal conversation has feelings in it instead of evidence. The measure has to be agreed before the build, because afterwards every available number flatters the thing that was built.
It should have been a web view
The content was three-dimensional and the interaction was not: people were looking at a thing rather than acting in a space. A browser would have reached everyone on the hardware they already own, cost a fraction, and needed no cleaning schedule. This is the finding we deliver most often, and it is the cheapest one to receive early.
A twenty-minute slot, and everything that is not learning
Set the slot you actually get with a person, then switch on the overheads a real deployment has. What is left in blue is the learning time — the only part of the session anybody is paying for. Most pilots budget for the blue and discover the rest in week two.
NO OVERHEADS SWITCHED ON YET
This is the slot as it is usually planned: twenty minutes, all of it learning. Switch on the four overheads above one at a time and watch where a real session actually goes.
Two of these overheads are one-off and two happen every single time. Onboarding and fitting are paid once per person, so they hurt most in a pilot where everybody is new and matter less in a programme people come back to. Cleaning and handover are paid on every user, forever — which is why they belong in the throughput calculation and in somebody's job description before the hardware is ordered.
A plain room, a cable, and somebody standing still
This is the honest photograph of spatial computing, and it is the reason there is no one in this page reaching into thin air. On Magic Leap 3 we built the R&D prototype as a WebXR experience with low-latency model output and an offline fallback, so the interface keeps responding when the connection does not — which is a deployment requirement dressed as a technical one, because the room you demonstrate in is never the room you deploy into. BCI × AR glasses R&D →
Comfort and tracking are requirements, not polish
These four get decided in the first week or they get discovered in the pilot. They are cheap as constraints and expensive as findings, and none of them is a matter of taste.
A floor rather than a target, because dropping below it is a comfort event rather than a visual one. It is agreed before the content is designed, and the content is then designed to hold it on the hardware your audience actually has — which is usually a generation behind the one on the engineer’s desk.
Motion-to-photon latency, and the mismatch between what the eyes report and what the inner ear does. Locomotion choices, acceleration, artificial turning and horizon handling are comfort decisions with a real cost in design freedom, and they are made deliberately rather than inherited from a template.
Inside-out tracking in a feature-poor room with changing light will drift and re-localise. The deliverable is not preventing that; it is what the user sees when it happens, how they recover without removing the headset, and whether the session resumes where it stopped rather than at the beginning.
A session that is enjoyable at four minutes and tiring at eighteen has a design problem that no amount of fidelity fixes. Weight, focal distance, hand-tracking precision and how much of the session is spent with arms raised all belong in the plan, next to the session length they constrain.
The same discipline applies to what we will not claim. We do not publish comfort statistics or learning-outcome figures for any client system, because none has been cleared for publication — and a comfort number without a cohort behind it is worth less than the sentence it sits in.
Three pieces of work, and what each one actually is
One is a product we build for a client, one is our own research, and one is a feature inside a consumer product that had to earn its place. The labels matter more than usual in this category, so they are on the left.
Client product
Silicon Valley
Where the third dimension is load-bearing
A platform that turns standard medical images into photo-realistic, interactive 3-D patients for surgical preparation and training. The hard part is that accuracy here is functional rather than aesthetic: rehearsing on an inaccurate model is worse than not rehearsing, so the reconstruction pipeline has to be reliable every time rather than impressive once. This is the case where being present with a three-dimensional thing genuinely changes what a person can do afterwards. It is training and rehearsal software — not a medical device, not clinically validated, not cleared by any regulator. Medical 3-D case →
EMOTIV · Magic Leap 3
WebXR
A Fluvius R&D prototype, and nothing more than that
An EMOTIV brain–computer interface paired with Magic Leap 3 AR glasses for hands-free interaction, built as a WebXR experience with low-latency model output and an offline fallback, alongside TheCap — our own smartcap concept. The hard part is turning a noisy biological signal into an intent a system can act on without acting on noise. We make no neurological, cognitive or health claim about any of it, and it is research rather than a product or a platform. BCI × AR glasses R&D →
AR inside a product
Mass adoption
An AR surface that had to justify itself against four easier ones
Augmented reality as one surface of a social-media marketing product that reached mass adoption across web, native mobile, AR, Alexa and Apple Watch — one architecture, many surfaces. The hard part is the test most AR features quietly fail: the same job could be done on a screen the user already had open, so the AR view had to be worth switching to rather than merely possible. That question is the one we ask first about any spatial feature, including yours. Read the case →
What is not here: a managed headset fleet run in production for a client. No case page on this site records one, so the deployment section below is written as a design position argued from first principles and from adjacent field work — not as a track record. If that is the part you need evidence for, say so on the call and we will tell you plainly where our experience stops.
Bring the outcome you want and the slot you get with a person. Those two decide almost everything else about a Data Flow Audit on this subject.
We go and look at the rig
A spatial-scanning rig, on a person, on a floor — harness, sensor head, battery across the chest, and a flight case just out of frame that somebody has to wheel. Almost every recommendation on this page comes from time spent with equipment like this: what it weighs after an hour, how long it takes to set up, how much room it needs, and who ends up carrying it. That is the least glamorous input into a plan and the one that stops the plan from being written for a room nobody has. About Fluvius →
The line items that decide whether the pilot survives the champion leaving
None of this is software, and all of it is the plan. When a sponsor asks what an XR deployment costs, this is the half of the answer that usually goes missing.
Charging, storage, cleaning, updates, scheduling and the person a user asks when something is wrong. Named in the plan, with an estimate of the hours, before the hardware is ordered. A pilot with no named owner has already chosen its ending.
Face interfaces, covers, wipes, drying time and the minutes it takes — which is why it appears as an overhead in the instrument above rather than as a footnote. In a clinical or teaching setting this is a policy question as much as a practical one, and it is answered before the rota is written.
Device management, kiosk mode so a user meets your application and nothing else, enrolment, update windows, and a spare that is actually charged. We build against this and write the runbook for whoever inherits it; we do not claim to have run a fleet in production for a client, because that is not on any case page here.
Play space and guardian setup, feature-poor walls, changing daylight, reflective floors, and where a person is standing when tracking goes. The room is a component, and it is the one component nobody puts in the budget.
The measure belongs here too, not in the software plan. Agreed before the build, compared against the thing it replaces, and read over weeks rather than on the day — because satisfaction on day one is mostly novelty, and the renewal conversation happens much later than that.
The work, as we actually sell it
Timelines are indicative ranges and depend on scope. The first one is deliberately the smallest, and it is the one we would rather you bought first.
Should this be XR at all?
1–2 WEEKSA written comparison against a 3-D view in a browser, a video and a physical rehearsal, with the total cost of a headset deployment included — the hardware and the hours around it, not only the build. You keep the document either way, and a fair share of these end with “not a headset”.
A pilot designed to produce evidence
8–16 WEEKSA defined cohort, a comparison against what it replaces, a measure agreed before the build, and session lengths that fit the rota people actually work. Designed so that a negative result is still a useful one, which is what separates a pilot from a demonstration.
The experience itself
10–20 WEEKSBuilt against a comfort floor rather than a fidelity target: frame-rate floor, motion tolerance, a tracking-loss recovery path, and an onboarding route a first-time user completes in under two minutes with nobody standing next to them.
Spatial data and 3-D from real sources
10–20 WEEKSGeometry generated from imaging or scans where the accuracy of the model is a requirement rather than a preference, and where the pipeline has to produce it reliably every time rather than impressively once.
Deployment and fleet reality
3–8 WEEKSDevice management, kiosk mode, charging, storage, hygiene, spares and the runbook for whoever ends up owning it. Costed as line items with hours against them, so the sponsor sees the whole number rather than the software half.
The web alternative, built properly
4–10 WEEKSWhen the answer is a 3-D view in a browser, we build that instead and write down why — reach on hardware people already own, no cleaning schedule, and a fraction of the cost. Our own R&D work is WebXR, so this is not a consolation prize.
Where the question is a character that responds in real time rather than a space someone acts in, the neighbouring page is the right one: Animation AI & Unreal Engine owns the render loop and the shared latency budget. This page owns spatial interaction and the deployment around it.
What you are probably thinking
The record behind the pages
Many of our clients have been with us for 7+ years straight. The Upwork and Clutch records are independently verifiable.
Looking for this as an engagement rather than a stack? 3-D, Animation & Computer Vision sells the team and the outcome. See also all our work and every service.
Not ready to talk? Take the checklist.
One page: 14 questions before you fund an XR pilot. How long the slot really is against the rota people work. Who owns charging and cleaning, by name. How long a first-time user takes to reach the first minute of learning. What happens on tracking loss and how a person recovers without help. What you will compare the result against, and when you will read it. And the total cost of everything that is not software.
Tell us what people should be able to do afterwards.
A free 30-minute working session, not a sales call and not a demo — there is nothing to demonstrate. Bring the outcome you want, who the people are, and how long you actually get with each of them. We will tell you whether a headset is the right instrument.
You keep a one-page read either way: the honest comparison against a web or video alternative, the total cost of a deployment including the parts that are not software, and the measure we would agree before building anything. A fair share of these end with “not a headset”, and nobody follows up more than once.
