Why cost guides for this are usually useless.
Search for WebXR development cost and you will find ranges wide enough to be meaningless — a few thousand at one end, six figures at the other, with nothing explaining what moves a project between them. That is not dishonesty. It is that “a WebXR project” describes a delivery mechanism, not a scope, in the same way “a website” covers both a landing page and a bank.
So this guide does two things differently. It publishes our actual figures, which are on our pricing page and are the same numbers we quote, rather than a range collected from other people’s marketing. And it spends most of its length on the drivers, because once you know what moves the number you can estimate your own project and evaluate anybody’s quote, including ours.
One honest caveat before the numbers: every figure below is a starting point for a defined scope. Anyone who gives you a fixed total before knowing what the 3D content is has either padded it heavily or is about to have an uncomfortable conversation with you later.
£ — the prototype tier, from £2,800.
What it is: one use case, one scene, representative rather than final assets, deployed to a URL you can send to anyone.
What it is for: answering a question that cannot be answered on a slide. Does this read as convincing at full scale? Will the people who have to approve it actually open it? Is the interaction obvious without a facilitator standing there?
What is in it: a working WebXR build, one interaction model, the flat desktop view designed rather than tolerated, hosting on HTTPS, and a link that works on a Quest browser and a laptop.
What is not in it: accounts, a database, analytics beyond page-level, a way for you to change the content, or production-final art.
Before this tier there is a smaller step worth knowing about. Our Idea Validation Sprint is £495 — a ninety-minute workshop, a feasibility review, an architecture outline, a roadmap and a budget estimate. Its most valuable outcome is frequently a recommendation not to build the thing, which is a very cheap way to save £2,800 and a month.
For a sense of scale: most of the individual experiences in our browser playground — the product configurator, the splat viewer, the physics sandbox, the spatial audio demo — are prototype-tier pieces of work. That is what the tier buys: one idea, working, in a browser, that you can put in front of someone.
££ — the pilot tier, from £9,000.
What it is: the version real users touch, with the machinery that implies.
The step up from prototype to pilot is not visual. It is almost entirely the invisible half: authentication, because now it matters who is looking; analytics that answer a business question rather than count visits; backend integration, because the content has to come from somewhere real; error handling and device fallbacks, because you are no longer standing next to the person when it breaks; and content that survives scrutiny, which usually means the asset work becomes serious.
This is also the first tier where performance stops being a nice-to-have. A prototype can be slow on a mid-range phone and still do its job. A pilot cannot, because the people you most need to impress are the ones on the worst hardware.
Two things commonly get missed in pilot budgets, and both are avoidable:
- The measurement plan. If nobody agreed in advance what result would justify the platform tier, the pilot will succeed and fail simultaneously depending on who is presenting it.
- Accessibility and the non-immersive path. For an internal rollout this is not optional, and retrofitting it costs more than building it.
£££ — the platform tier, from £28,000.
What it is: a system that other people operate, that you own, and that outlives the project team.
What pushes a project into this tier, in rough order of how much each one costs:
- Multi-user. Shared state, presence, voice, and the server infrastructure underneath it. This is the single most expensive feature in XR and it is routinely specified as a bullet point. If people need to be in there together, budget for it deliberately.
- A CMS. Someone who is not a developer needs to change the content, or you have bought a thing that decays. This is the feature with the best long-run return and the one most often cut first.
- Enterprise integrations. SSO, the CRM, the PLM or asset system, the LMS. Each one is its own small project with its own stakeholder.
- Device management. If headsets are involved as physical objects — kiosks, a training room, a fleet — someone has to own charging, enrolment, updates and breakage.
- Support and change. Our advisory and retainer support starts at £1,500 a month. Something at this tier needs it; the alternative is a system that quietly stops being true.
Two of our published fixed packages sit alongside this ladder rather than inside it: a Rapid MVP Sprint from £2,995 for a two-week build path, and an AI Integration Sprint at £1,995 where the immersive layer needs to sit on top of a model or an automated workflow.
The seven things that actually move the number.
Feature lists are a poor predictor of cost. These seven are a good one.
- How much 3D has to be created. Almost always the largest single variable, and almost always underestimated, because it is treated as an input to the project rather than part of it. Existing CAD is a head start, not a finished asset — converting engineering geometry into something that renders in real time is a real workstream. A photogrammetry or Gaussian-splat capture can be dramatically cheaper than modelling if the thing already exists in the world.
- Whether one person or many are in the scene. Single-user to multi-user is not an increment. It is a different system with different infrastructure and a different failure mode.
- How many devices must be first-class. Supporting Quest properly, phones properly and desktop properly is three testing surfaces and three sets of design decisions, not one build with three URLs.
- Whether anyone else needs to change it. A hardcoded experience is fast to build. An editable one costs more up front and less every month thereafter. Decide this at the start, because retrofitting an authoring layer is close to rebuilding.
- What it has to connect to. Every enterprise system it touches brings integration work, a security review, and a stakeholder with an opinion. Two integrations is not twice one integration.
- Whether it is measured. Real analytics — what people looked at, where they stalled, what they completed — is engineering work, not a switch. It is also usually what secures the next round of funding.
- Who owns it in a year. The cheapest thing to build is the thing nobody can maintain. Documentation, handover and a sane architecture are a real cost and a much smaller one than the alternative.
Cheaper than buyers expect, and more expensive.
Cheaper than expected:
- Distribution. There is no store fee, no submission cycle, no enrolment programme, no sideloading instructions. For anyone who has run a native XR pilot inside a large organisation, this alone changes the arithmetic.
- Updates. A fix is a deploy. Every user has it immediately. Native programmes budget for release management; web ones do not have to.
- Reaching people without headsets. The same build serves the desktop audience, so you are not commissioning a second flat version for the majority.
- Capture, when the subject already exists. Gaussian-splat capture of a real space is often faster and cheaper than modelling it, and more convincing.
More expensive than expected:
- Content, always. If you take one number away from this article, make it this: on a typical project the 3D content costs more than the software.
- Multi-user. See above. It is the feature most likely to double a budget after the quote is signed.
- Performance on the worst device you promised to support. That promise is a cost. Make it deliberately.
- The flat view, if it was treated as a fallback. It is the majority experience. Designing it late means designing it twice.
How to get a number you can actually rely on.
Four steps, in order, and none of them require committing to a supplier.
- Write down the decision this has to support. Not the feature — the decision. “A buyer chooses a configuration without a showroom visit.” “A new starter completes the induction without a trainer.” If you cannot write that sentence, no estimate will be meaningful, because nobody knows when it is finished.
- Inventory the 3D you already have, and be pessimistic. A CAD model built for manufacture is not a real-time asset. Knowing what state your geometry is really in moves an estimate more than any other single fact.
- Decide who has to be able to change it. Answer this before the build, not after.
- Buy the smallest thing that answers the question. A £495 validation sprint, or a £2,800 prototype, is a cheap way to find out whether the £28,000 version deserves to exist. Most XR programmes that fail did not fail at the build — they failed by committing to a platform before anyone had evidence the idea worked.
All the figures here are published on our pricing page and are what we quote. If a project does not fit them, we will say so.
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.
