What Virtual Reality is, and what it is not
Virtual Reality replaces a user's view of the real world entirely, placing them inside an environment the studio controls from end to end.
That total replacement is what makes the category commercially distinct. Because nothing of the real room survives, the studio is responsible for every surface the user sees, and the content bill scales with how much of that world has to be believable. A training simulation set in one room costs a fraction of one set across a facility, and the difference is modelling and testing rather than code.
Virtual Reality is not Augmented Reality, which leaves the real view intact and adds to it. The boundary with Mixed Reality is the one that causes real confusion, because modern headsets do both. A device with passthrough cameras can run a fully virtual scene one minute and a room-aware one the next, so the hardware no longer settles which category a project belongs to. The deciding question is whether the user needs to see and use the real room. If they do, the project is not Virtual Reality regardless of the headset it runs on.
What hardware ships today
The decision that shapes a Virtual Reality budget is standalone against PC-tethered, and it is made early and reversed expensively.
A standalone headset runs the application on the device itself. It requires no host machine, sets up in minutes and can be deployed to sites with no technical staff, which is why the large majority of published enterprise work runs on one. The constraint is a mobile-class processor, so scene complexity, simulated physics and rendered fidelity all have real ceilings.
A tethered headset borrows a workstation's graphics power and lifts those ceilings substantially. It buys fidelity at the cost of mobility, a machine per headset and a technician near it. Engineering-grade visual review and high-fidelity simulation still justify that trade. Very little else does.
The trap is treating this as a hardware decision. It is a content decision, because the same experience built for tethered hardware does not simply run on standalone, and porting late in a project usually means rebuilding assets rather than recompiling. Settle the target before asset production starts, not after a pilot.
Headset list prices are not quoted here. Manufacturer pages serve different prices by region and change them without notice, so a figure published on a register page ages badly and misleads a buyer building a business case. Price the exact configuration with the manufacturer, and remember that a fleet costs far more than the headsets: charging, storage, hygiene, provisioning and breakage are the lines that surprise people.
What enterprises actually deploy
Published Virtual Reality work is dominated by training, and the concentration is much heavier than the category's marketing suggests.
The register supports that directly, because every case study on a record traces to a public source. Across the studios currently on record, training and simulation is the single most common use case attached to Virtual Reality work, and safety training is the most common variety within it.
The pattern is consistent across sectors. 4Experience publishes safety and procedural training for DPD and STRABAG. Bit Space Development documents hazard training for Canadian National Railway and trades training for the Manitoba Construction Sector Council. The shared logic is straightforward: each rehearses something that is dangerous, expensive or disruptive to practise for real.
A second, smaller cluster covers experiences where the subject cannot be visited. Magnopus published Mission:ISS with NASA, and a global launch for Jaguar. These are not training. They are access, and they are commissioned and measured differently.
What the published record does not support is the collaboration and virtual-office narrative that absorbed a great deal of attention. Very little of it appears in case studies relative to how heavily it was promoted, and a buyer scoping that use case should ask for delivered examples rather than platform demonstrations.
What drives the cost of a build
No credible public source publishes what a Virtual Reality project costs, and this register does not publish one either.
That is a position rather than an omission. Price data on studio directories is self-reported through a submission form, which makes it a marketing figure rather than an observation, and a register that ranks on public evidence cannot convert one into a fact. What is stateable is what moves the number.
Four things dominate a Virtual Reality estimate.
- Environment scope. The number of distinct spaces the user can occupy, not the hours of content. Each space is modelled, lit, optimized and tested separately.
- Interaction depth. Looking at a scene is inexpensive. Manipulating tools, following a branching procedure and being assessed against it are each a step change, because every added interaction multiplies the states that must be tested.
- Fidelity target. Whether the simulation must merely represent the task or behave correctly under physics. Engineering-grade behaviour is a different discipline from visual realism and costs more than it.
- Fleet and integration. Device management, offline operation and reporting results into an existing learning system are routinely underestimated, and the reporting integration is frequently the longest pole.
Ask a studio which of those four dominates its estimate. A studio that has delivered answers immediately and specifically. One that has not answers with a total.
How long a build takes
Timeline is governed by asset production and by access to the thing being simulated, not by application development.
This is where schedules slip. A procedural simulation cannot be built accurately until someone who performs the procedure has sat with the team, and getting that person for long enough is an organizational problem rather than a technical one. Reference material for the environment, whether photographs, scans or drawings, sits on the same critical path.
Sequence accordingly. Subject-matter access and reference capture should start before the application does. Assessment logic, if the training has to produce a score, should be specified in writing early, because it determines the data model and is expensive to retrofit.
The register does not hold delivery timelines, because studios do not publish them consistently enough to compare. Treat any timeline quoted before the subject-matter and integration questions are settled as an estimate of the software alone.
How to assess a studio
Ask for delivered work in your scope, then check whether the studio describes it by client or by feature.
That single filter separates the population quickly, and it is the one this register applies before a company is eligible at all. Work organized by client, describing what was delivered and for whom, is evidence. Work organized by capability, describing what the studio could do, is a brochure. The methodology behind that standard is published in full so a buyer can apply it without trusting the register.
Three further checks earn their time on Virtual Reality projects specifically.
Ask which headset the delivered work shipped on, not which the studio supports. Capability pages list every device a studio would accept work on. Case studies name the one a project actually ran on, and the gap between the two lists is often wide.
Ask how results leave the headset. Training that produces no record is difficult to justify a second year, and the reporting path is the part most often deferred and least often specified.
Ask who owns the environment assets afterwards. A modelled facility has value beyond the first project, and ownership is far easier to settle before the work than after it.
What the published record does not tell you
Published Virtual Reality case studies rarely name the headset, and they almost never carry a date.
Around one in seven names a target platform and fewer than one in ten carries a year. The same studios name their clients in most cases, so the omission is selective rather than general. For a category where the hardware decision drives comfort, session length, fleet cost and the shape of the build, that is the single least helpful field to leave out.
The practical effect is that a portfolio proves a studio has built Virtual Reality software and does not prove it has built for the device under consideration. Standalone and tethered work differ in performance budget, in how content is loaded and in what a support contract has to cover. A studio that has shipped only tethered work is not thereby unable to ship standalone, but the transition is a real one and it belongs in the conversation rather than in an assumption.
Asking for the device, the build date and the current support status of any project in a pitch deck is reasonable. This register records a platform only when a third party attests to it, a rule set out in the methodology, which is why platform coverage is sparse here by design rather than by omission.
Further published work in this category
Virtual Reality work in the register divides between workplace training and institutional projects, and the second group is easy to overlook.
4Experience publishes MissionOne, a soft skills training application naming both Meta Quest and Pico as targets, which is unusual enough in this corpus to be worth noting. Soft skills is also a harder assessment problem than procedural training, because the thing being rehearsed is a conversation rather than a sequence.
Institutional and clinical commissioning appears steadily. Draw and Code publishes SHELTA, a mental health support application built with the University of Liverpool for Meta Quest, and Bit Space Development publishes Professor Guidence with the University of Manitoba. Both were commissioned by universities, which usually means a named research lead and a stated objective, and that combination produces better documentation than most commercial work.
Where these projects fail
Virtual Reality projects fail most often after the software is delivered, not during the build.
The common pattern is a successful pilot that never scales, and the cause is usually device logistics rather than content. Headsets have to be charged, updated, cleaned, assigned to people and recovered afterwards. A pilot with ten devices absorbs that work informally. Two hundred devices across several sites is an operational programme with an owner and a budget, and a project that did not name that owner tends to stop at the pilot.
The second failure is comfort and session design. A build that assumes a thirty minute session when the realistic tolerance for new users is closer to fifteen produces poor completion regardless of quality. That constraint is known at design time and is cheap to accommodate early and expensive to retrofit.
Third, integration is deferred. Training that has to report completion into an existing learning system, or visualization that has to read from live engineering data, carries integration work that is frequently scoped as a later phase and then arrives as the reason the project stalls. Where results have to land somewhere, that destination belongs in the first conversation.
A fourth failure is quieter than the others. Support is agreed as a warranty period rather than as a service, so when a headset firmware update changes behaviour eighteen months later there is no one contracted to respond. Platform updates are not optional and they do not wait for a budget cycle, which is why an ongoing arrangement is worth pricing at the start even where it looks like an avoidable cost.
Where to go next
Every studio referenced here is on the public record with its sources and its verification date. The complete list of studios delivering this work is the Virtual Reality development register, which is the browsable index rather than a ranked subset.
For a ranked view of one scope beneath this pillar, the register publishes a ranking of studios with published Virtual Reality training work. It covers the deepest use case in this category and states the evidence behind every placement.
Rankings are scoped to a service, an industry, a use case or a location rather than to the category as a whole, because a studio strong in safety training is not thereby strong in engineering visualization. There is no single best Virtual Reality company, and a list offering one is answering an easier question than the buyer asked. The suppliers documented here overlap heavily with three other pillars. Almost every studio delivering Virtual Reality work also delivers Augmented Reality development, and a majority deliver Mixed Reality development, so the technology named in a brief rarely narrows the field on its own.
By use case, training and simulation is where the published Virtual Reality record is deepest, and product visualization is the next largest. Among sectors, healthcare carries the most documented Virtual Reality work and the most specific constraints on who may deliver it.
