TL;DR: Headsets get chosen in a demo room and used in a fire ground, a clinic room or a warehouse aisle, and the gap between those two places is where most enterprise XR projects quietly die. Pick for the deployment, not the demo. Start from the sensor your product actually depends on, because a measurement that is not in the hardware cannot be added in software. Then ask who puts the thing on their head, how long they wear it, who cleans it, who charges it, and who pushes the next build to it. Standalone versus tethered is a question about the room, not about performance. Device management, battery logistics and the tracking environment decide more deployments than frame rate does. Whatever you pick, keep your logic portable and expect the per-device tuning to be thrown away.
Most of the hardware conversations I have been in started at the wrong end. Someone has seen a demo, the demo ran beautifully, and the question on the table is which headset has the best passthrough or the highest resolution. That question almost never decides whether the project works.
I have shipped XR in two places where the answer mattered: the ERIS XR platform and AR tools at ARCortex, built for the fire service, and clinical eye-tracking diagnostics on Vive Focus 3 as CTO at Nystag Healthcare XR. Two completely different environments, one shared lesson: the headset is a deployment decision wearing a hardware costume.
Here is the order I would work through it now.
Start from the sensor, not the spec sheet
The first question is whether the device physically contains the thing your product measures or displays. This sounds obvious and it is the single most common way to get stuck.
At Nystag the product was a clinical eye-tracking diagnostic. Eye tracking is a hardware capability: cameras pointed at the eyes, sampling at a known rate, with a calibration routine you can trust and repeat. No amount of engineering turns a headset without that hardware into one with it, and no clinician is going to accept an inference where a measurement belongs. That constraint eliminated most of the market before any other criterion was considered, which is exactly what a good first constraint does.
The same logic applies to depth sensors, passthrough colour fidelity, hand tracking accuracy, positional tracking outdoors, and any interface that has to work through gloves. Write down the one capability your product cannot exist without, verify it exists in hardware, and only then start comparing devices. If two candidates both clear that bar, you now have a real choice. If only one clears it, you do not have a decision to make, you have a dependency to plan around.
Then ask who puts it on
The second question is about the human, and it is the one that separates a demo from a deployment.
A firefighter wearing gloves and possibly a mask cannot use a controller with small buttons, cannot read low-contrast UI in direct sunlight, and does not have a spare hand. A patient in a clinic wears the device for a few minutes, hands it back, and the next patient wears it twenty minutes later, so fit adjustment and hygiene between sessions are part of the workflow rather than an afterthought. A warehouse operator wears it for a shift, which makes weight distribution the entire product.
Each of those is a different device profile. Field use wants ruggedness, glare tolerance and no fiddly setup. High-turnover clinical or retail use wants fast donning, wipeable surfaces, swappable face interfaces and a calibration routine that takes seconds. Long-shift use wants a rear-mounted battery and a balanced front.
This is also where accessibility stops being a checkbox. Interpupillary distance adjustment, prescription lens inserts and a device that fits a range of head sizes decide whether a third of your users can actually use the product. In a clinical context those are not comfort features, they are prerequisites for a valid measurement.
Standalone versus tethered is a question about the room
The rendering argument for a tethered headset is real and mostly irrelevant. What decides it is where the device lives.
If the environment is a controlled room that the same organisation owns, with power, a machine you can lock down and a fixed setup, tethered is entirely reasonable and buys you a rendering budget you will otherwise spend a month optimising for. If the device travels, if it is used by someone whose hands are full, or if it goes anywhere with weather, standalone is the only sane answer and your app has to live inside a mobile-class GPU budget from day one.
Decide this before the first sprint, because it changes how you build. A standalone target means the same discipline that shaped every Unity project I have worked on: a frame budget you treat as a hard constraint, not something you optimise towards at the end. Porting a tethered experience down to standalone late is not a port, it is a rewrite of the rendering half of the product.
Device management is the feature nobody demos
This is where enterprise XR is different from consumer XR, and it is the section that gets skipped.
Ask the boring questions early. How does a build get onto twenty devices that are not sitting on your desk? Does the device require a personal consumer account to be signed in, and is that acceptable to the client's IT and legal teams? Can it be locked into a single application so a user cannot wander into the system menu? Can firmware updates be deferred, or does the fleet update itself overnight and change behaviour you have already tested?
That last one deserves emphasis. An auto-updating headset is an unpinned dependency in your production stack. It will change a permission model, a hand-tracking behaviour or a passthrough setting at some point, and it will do it on a schedule you do not control. The same problem shows up in AI work, where a model version moves underneath a live agent, and the mitigation is the same: know your versions, keep a frozen set of tests, and re-run them when the platform notifies you of a change.
Related, and learned the hard way in the field: every build must say what it is. Version, build number and commit hash visible on a screen the user can reach. Headsets pass between hands with no install history, and when someone reports a bug from a field session, the first question is which build they were wearing. Without an answer on screen you are guessing.
Battery and charging are a scheduling problem
Session length is not a battery spec, it is a workflow constraint. Two hours of stated battery life means something quite different for a twelve minute clinical session with a turnaround between patients than it does for a four hour training exercise.
Work out the real duty cycle: how many sessions per day, how long between them, who is responsible for putting devices back on charge, and what happens when someone does not. Then check whether the device supports charging while in use, whether the battery is swappable or hot-swappable, and how many charging ports the site actually has. A deployment where devices are dead at 2pm is a deployment that gets described as unreliable, and nobody will remember that the software was fine.
The tracking environment breaks more pilots than the headset
Inside-out tracking is very good now and still environment-dependent. Featureless white rooms, low light, reflective surfaces, moving crowds and direct sunlight all degrade it, and they degrade it precisely in the places enterprise work happens.
Outdoors, the problem compounds. Anything that anchors content to the real world runs into the fact that geospatial AR is a coordinate problem before it is a graphics problem, and the dominant error is usually heading rather than position. That is not fixed by a better headset. It is fixed by designing for the uncertainty: showing the confidence, offering a view that does not depend on the noisy sensor, and never presenting a placement as more certain than it is.
Test in the actual environment before committing to a fleet. One afternoon on site with one device tells you more than every spec sheet comparison you will read.
Keep the logic portable and expect the tuning to be thrown away
The device you pick today is not the device you will be on in three years, so structure the code accordingly.
The rule I took from building a cross-platform SDK at Geonode applies directly: share the logic, never the platform. Your domain model, state machines, data layer and business rules belong in plain C# with no device types in them. The device-specific parts, input mappings, tracking setup, rendering settings, permission flows, sit behind a thin boundary. Cross-device abstractions like OpenXR and AR Foundation help with the boundary, but they do not make devices equivalent.
And be honest about what will not transfer. Comfort tuning, interaction distances, text sizes, hand-tracking thresholds and passthrough-dependent visual design are calibrated against one device's ergonomics and optics. Moving hardware means redoing that work with real users, and budgeting for it is more useful than pretending an abstraction layer prevents it.
The short version
- Identify the one hardware capability your product cannot exist without and eliminate everything that lacks it.
- Design around the wearer: gloves, session length, turnaround, hygiene, fit range, prescription lenses.
- Choose standalone or tethered based on the room, and set the rendering budget on day one.
- Ask the device management questions before buying: deployment, accounts, kiosk mode, firmware update control.
- Treat battery and charging as a scheduling problem tied to the real duty cycle.
- Test tracking in the actual environment, outdoors included, before committing to a fleet.
- Put version, build number and commit hash on screen so field reports are actionable.
- Share the logic, never the platform, and budget for re-tuning when the hardware changes.
The pattern underneath all of this is the same one I now apply to AI systems: the interesting engineering is rarely the demo, it is everything that has to keep being true after the demo ends.
I build XR and AI systems for teams across the US, UK and Europe, from AR platforms for public safety to production voice agents. More about my work here, or book a call.