The automotive XR programme usually starts at the wrong end.
The pattern is consistent enough to be predictable. Someone senior sees an immersive vehicle demo at a motor show or a supplier day. A pilot gets funded. Three headsets arrive at one flagship site. There is a launch, a photograph, and a genuinely impressed first fortnight. Then the headsets go in a drawer, because nobody has budgeted for the person whose job it is to charge them, and the content is a version behind the moment the trim options change.
Almost none of that is a failure of the technology. It is a failure of ordering. The programme committed to the hardest distribution model available before anyone had established what the experience needed to do, who would open it, or how often it would change.
The headset was never the risky part. The risky part was buying an audience of three before knowing whether anyone wanted the content.
Reverse the order and the same money buys a great deal more information. A browser build puts the same vehicle in front of the entire dealer network, the whole engineering group, the agency, the press list and the board, on the laptops and phones they already carry, in the first week. If the content is wrong, you find out in the first week too.
The expensive part is the asset pipeline, and it barely cares which architecture you pick.
This is the single most useful thing to understand before commissioning anything, because it changes what you are actually buying.
Getting a vehicle from engineering data into any real-time experience is a sequence, and the sequence is almost entirely independent of whether the result runs in a browser, in a headset app, or on a server GPU.
| Stage | What it involves | Architecture-specific? |
|---|---|---|
| Data release | Getting CAD or class-A surfaces out of engineering, with permission and a version you can rely on | No |
| Tessellation and cleanup | Converting NURBS to polygons, removing internals nobody will ever see, fixing normals | No |
| Decimation and LODs | Reducing to a real-time budget without destroying silhouettes and panel gaps | Partly — the budget differs, the work does not |
| Materials and UVs | Paint, chrome, glass, interior fabrics, carbon, brushed metals. The part that decides whether it looks like the car | No |
| Variant rig | Structuring trims, colours, wheels and packs so they can be switched rather than rebuilt | No |
| Lighting and environment | Studio HDRI, reflections, shadow strategy | Partly |
| Runtime and interface | The actual application | Yes — and it is the smallest line |
Read the right-hand column again. The overwhelming majority of the effort produces an asset that a browser build, a Quest build and a CloudXR-streamed build all consume. Which means a browser-first programme is not a throwaway prototype that gets replaced. It is the first customer of a pipeline you were always going to need.
The corollary matters just as much. If a supplier quotes you a headset app and a browser app as two separate projects at two full prices, ask which stages in that table they are charging you for twice.
What a browser build settles that a headset app cannot.
Five things, and every one of them is information you need before committing to a native programme.
Whether the content works at all. Configurators fail for unglamorous reasons: the paint reads wrong under the chosen lighting, the interior camera cannot get to the seat position people care about, the trim taxonomy makes sense to product planning and to nobody else. All of that surfaces faster with two hundred people looking than with three.
What people actually do with it. A web build carries ordinary analytics. Which trims get configured, where sessions end, which options are opened and abandoned, how long a session lasts, what happens on mobile versus desktop. That is a genuine input to product and marketing, and it is the evidence a second-phase business case is made of. Installed headset apps in a retail environment are, in practice, measured by anecdote.
Whether the dealer network will use it. This is where most automotive digital programmes actually die. A dealer principal will open a link. A dealer principal will not run a device management programme. If the tool has to reach a franchised network, a URL is not a convenience, it is the entire feasibility question.
How it behaves inside the systems you already have. A browser build can sit inside the model page, hand a specification to the CRM, deep-link from a campaign, and be shared to press and agencies without a build being distributed to anybody. Deep-linking a configuration into an email is a small feature that changes how the whole thing gets used.
How fast it can change. Automotive content has a hard clock: model year, facelift, option pack, pricing, regional availability. On the web, publishing a change and knowing everyone has it are the same action. In a native programme they are two problems, and the second one never fully goes away.
Five browser-first jobs, in rough order of payback.
1. The retail configurator. The obvious one, and still the one with the clearest return, because it sits directly on a purchase journey you already measure. The web version reaches the whole audience including the majority who are on a phone. This is the pattern behind our own product configurator demo — a normal web interface wrapped around a 3D viewer — and it is what most product and manufacturing briefs turn out to want once you strip the language back.
2. The dealer and fleet specification tool. Less glamorous, frequently more valuable. A salesperson or a fleet manager building a real specification against real availability, with the visual there to settle the conversation. It reaches a franchised network without a deployment programme, and the thing it produces — a specification — is structured data you can act on.
3. Design and engineering review. A shared, versioned view of a proposal that stakeholders can open from a calendar invite. Be honest about the boundary here: a browser will not render a full-fidelity CAD assembly, and if the review genuinely requires the master data at engineering accuracy, that is a remote rendering problem rather than a web one. Most reviews do not require it — they require a specific decision supported, and the asset that supports the decision is much smaller than the master file.
4. Aftersales and service visualisation. Parts identification, service procedure explanation, damage and repair discussion with a customer. High-frequency, low-drama, and it lives or dies on being one tap away inside an existing service portal. That is a web requirement by definition.
5. Event, motorsport and audience experiences. Where the audience is large, temporary and using their own devices, an install is a tax on attendance. A link on a QR code is not.
What a browser build genuinely cannot do — which is how you specify the native app.
The point of building the web version first is not to prove the headset is unnecessary. It is to arrive at the headset with a specification written from evidence. These are the honest limits, and each one is a requirement in disguise.
- True 1:1 scale presence. Standing next to the vehicle, judging shoulder room and sightlines with your own body. This is real, it is not reproducible on a monitor, and it is the single best argument for a headset in this sector.
- Full-fidelity engineering data. If the answer must come from the master assembly rather than a prepared representation, on-device browser rendering is the wrong tool. Remote rendering exists for exactly this, and we have written about where that stops being worth the GPU bill.
- Offline operation. Showroom floors with hostile Wi-Fi, and factory or workshop environments with none. If it has to work with no connection, that is an installed application.
- Long, high-intensity simulation. Sustained driving with real vehicle dynamics, physics and scenario state. Our own driver assessment work is a desktop simulation for exactly this reason, and putting it in a browser tab would have been an ideological decision rather than an engineering one.
- Precise, occlusion-correct AR at vehicle scale. Placing a virtual car on a real driveway convincingly is still better served by native AR frameworks.
Notice how specific that list is. A native business case built from it reads we need 1:1 scale evaluation for the interior package review, for twelve people, at two sites. That is fundable. We should do something in VR is not.
What we have built in and around this sector.
Being precise about this matters more than sounding impressive, so here is the actual position.
Motorsport, at scale, cross-platform. We built the A2RL VR application for Focal Point VR — a live streaming and immersive racing experience for the Abu Dhabi Autonomous Racing League, the first extreme autonomous racing series. It recreated the Yas Marina Circuit, blended live race video with interactive 3D, and wired live telemetry — speed, position, overtakes — into 3D interface elements updating during the race. It shipped for the inaugural race on 27 April 2024, which drew more than 10,000 live spectators and over 600,000 online viewers within twelve hours, and it was built for Quest 2, Quest 3 and Quest Pro alongside mobile and desktop. The case study is here.
That project is a useful reference precisely because it is the opposite of this article’s advice, and correctly so. A live broadcast event with a fixed date, a controlled device list and a fidelity requirement is a native build. Knowing which projects are that shape is the whole skill.
Driver behaviour and assessment. A desktop driving simulation that assesses already-trained drivers against six real incident scenarios before teaching anything, then assigns modules for what they missed and writes the result back to the client learning system. That one is here. Again: native, deliberately.
Browser-delivered 3D and configuration. The browser playground, including the configurator pattern above, and Simam Immerse, a headset-grade immersive media player that arrives as a link and needs no store submission.
What we have not done: shipped a retail configurator for a vehicle manufacturer. The pipeline, the configuration logic and the browser delivery are work we do regularly in other sectors; the automotive brand and CAD-release side of it would be new to us. That seemed worth saying in an article aimed at automotive buyers.
The sequence that works.
Four steps, each with a decision at the end of it. The point of the sequence is that you can stop after any of them and still own something useful.
- Decide what the experience must prove. Not what it should contain — what it should tell you. A day of structured discovery is enough for this, and our Idea Validation Sprint at £495 exists because so many briefs cannot answer it yet.
- Build the flat web version of the single most valuable moment. One vehicle, the real trim taxonomy, the actual interface. Prototype tier, from £2,800. Put it in front of a real audience and read the analytics rather than the reactions.
- Extend to a pilot with the systems attached. Real data, CRM handoff, the dealer or engineering workflow around it, on the devices those people really use. Pilot tier, from £9,000. This is the phase that produces a defensible business case.
- Then, and only then, decide about the headset. By this point you know which moments need 1:1 scale, how many people need them, and how often the content changes. That is a specification. Platform tier work starts from £28,000, and it should be spent against a requirement rather than an ambition.
Our full tiers are on the pricing page, and the cost guide explains the seven factors that move those numbers more than anything on a feature list.
One closing observation from doing this repeatedly: the flat view is not the compromise. For most automotive audiences it is the product, because the overwhelming majority of sessions will never enter an immersive mode. Design it first, design it properly, and treat the headset as the upgrade for the people who genuinely benefit from it.
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.
