TL;DR: Most of what gets sold as a digital twin is a 3D model with a dashboard sitting next to it. A twin earns the name when three things are true at once: the geometry is accurate enough for the decision it supports, live data from the real thing is bound to the right parts of that geometry, and somebody owns keeping it current after the physical world changes. Those three, not the rendering, are where the budget goes and where these projects fail. Here is how twins actually get built, where they change what people do, where they are expensive theater, and how to scope one so you do not end up buying a 3D animation with a subscription attached.
What a digital twin actually is
It helps to separate three levels, because vendors use one word for all of them and buyers pay for one while picturing another.
A spatial replica. An accurate 3D representation of a real place, asset or machine. Static. It is genuinely useful for orientation, planning, training and getting people to agree on what exists, but it describes how something is built, not how it is doing. Most demos are this.
A replica bound to live state. The same geometry, with parts of it connected to real signals: sensors, control systems, ticketing, occupancy, position feeds, work orders. Now the model shows what is true right now, and spatial context turns a table of readings into something a person can act on at a glance. This is the level most buyers actually want.
A twin you can ask questions of. The model plus enough modeled behavior to simulate: what happens if this line runs faster, if this route closes, if this unit fails at peak load. Real, expensive, and worth it only when the simulation changes decisions that carry serious cost.
Most disappointment comes from paying for the first while expecting the second, or commissioning the third before the operation trusts the data feeding the second.
The four things that decide whether a twin works
None of them is the visual quality, which is the thing every proposal leads with.
Capture: how the physical thing becomes data
Your starting material decides a large share of the budget before anyone writes code. Laser scanning gives you dimensional accuracy and a mess of points that still has to be turned into usable geometry. Photogrammetry from photos or drone footage is cheaper and looks convincing, with accuracy that varies with how carefully it was flown. CAD or BIM files are the best case when they exist and are current, which for anything built more than a few years ago is a real question rather than an assumption. And some assets simply get modeled by hand from drawings and site photos.
Whatever the source, none of it is shippable as-is. The path from survey data or a CAD assembly to something that renders in a browser or a headset is its own workstream, which we break down in the 3D content pipeline behind an XR app. Ask any vendor what they are capturing from and who is paying for that capture, because on a large site it can outweigh the software.
The live data binding
This is the part that separates a twin from a model, and it is mostly an integration project rather than a 3D one. Three questions decide the effort: which systems the data comes from and whether they have usable interfaces, how fresh it has to be, and what the twin does when a feed goes quiet.
That last one gets skipped and it matters most. A twin showing a stale reading with no indication that it is stale is worse than no twin, because people trust the picture. Any system that presents live state needs to be explicit about what it does not currently know.
Planes XR, a location-based AR experience we built for ARCortex, is a small clear version of this idea: it pulls live aircraft data from OpenSky and renders real plane simulations over live maps in the real world. The 3D is the easy half. Making a live feed line up with the physical world reliably is the engineering, and the same is true of the general case, which we cover in how location-based AR works.
Spatial accuracy, decided by the decision
Twins do not need to be accurate. They need to be accurate enough for the specific judgment somebody makes with them, and that tolerance ranges enormously. Knowing which floor and which end of the building a valve is on is a different requirement from knowing where a bracket sits to the millimeter, and the second one can cost many times the first for the same square footage.
The useful exercise is to name the decision first and derive the tolerance from it. Buying accuracy nobody uses is the most common way to spend a twin budget on nothing.
The update path
Physical things change. Sites get refitted, lines get re-tooled, a room becomes storage, a machine is replaced with a different model. The moment the twin and reality diverge, the twin starts producing confident wrong answers, and people stop opening it. This is how most twins die, quietly, in year two.
So the update path is a scoping question, not an afterthought: who notices a change, how does a changed real-world thing become an updated asset, how long does that take, and is it documented or living in one artist's head. If a proposal has no answer, you are buying a snapshot with a shelf life.
Where the twin gets used changes what you build
A twin is not one product, it is a data layer plus one or more surfaces, and the surface is a real cost decision.
A browser view is the cheapest to reach and right for planning, reporting and anyone who needs the twin from a desk. Phone or tablet AR puts it on the site itself, so a technician can hold the layer over the real thing, which is the pattern behind enterprise AR training. A headset build buys immersion and hands-free use at a higher cost per seat and a real deployment burden, which we walk through in which XR device you should build for. An operations-room display is different again, because a screen watched continuously has different rules from one someone opens twice a week.
The mistake is promising all of them. Pick the surface where the decision actually gets made, build that one properly, and add companions deliberately, each reduced rather than a copy of the primary experience.
Where digital twins genuinely earn their keep
Four patterns, and a fifth thing to avoid.
Preparing for a place you cannot practice in. When people have to act inside a physical space under time pressure, knowing the layout before arriving is the whole value. ERIS XR, an XR platform we built for ARCortex, helps firefighters pre-plan and train more effectively by blending digital and physical worlds in real time. Pre-planning a building is the clearest case for a spatial twin there is: the responder is not looking at a nice model, they are arriving somewhere they have already been.
Operational awareness where space is the story. When what matters is where things are relative to each other, a list cannot carry it and a map with live state can. This is the level-two twin doing what it is for.
Training and onboarding on real facilities. A twin is the content layer for training people on equipment and environments that are dangerous, remote, expensive to take offline or simply busy, which is the argument we lay out in VR training for high-risk teams. Building the twin once and reusing it for both operations and training is where the economics often improve.
Agreeing on a change before it is physically made. Layout changes, new installs, access and clearance questions. Arguing over a shared accurate model is faster and cheaper than discovering the problem on site, and it does not require live data at all.
And where it is theater. A rotating 3D building on a wall screen, next to a chart nobody reads, is a very expensive way to look modern. The test is simple and worth applying before you commission anything: name a person, a decision they make regularly, and what they would do differently with the twin than without it. If that sentence is hard to write, the project is not ready.
What it costs and what moves the number
Twins sit inside the same cost logic as other immersive and spatial software, and the honest price bands are in our XR app development cost guide rather than invented fresh here. Five things move the number more than anything else:
- Scope of the physical envelope. One machine, one room, one building, one campus. This scales with real work, not with a slider.
- Capture method and required accuracy. Reusing current CAD is the cheap path. Surveying a site that was never documented is a project of its own.
- Number and quality of live integrations. Each system is a small project inside the project, and the ones without decent interfaces are the expensive ones.
- How many surfaces. Browser, on-site AR, headset, control room. Each is a build, not a checkbox.
- The update model. A twin maintained quarterly by a named owner and one that is expected to reflect changes within a day are different systems.
How AI changes the math, and where it does not
The software wrapped around a twin is exactly the kind of work that compresses hard with AI coding agents under senior review: ingestion pipelines, APIs, dashboards, permissions, the large volume of ordinary screens any operational system needs. That is the same ship-in-days approach we apply everywhere, and it means a twin that was an enterprise-only project a few years ago is now reachable for a mid-sized operation, the same threshold shift we described for custom vertical software.
Computer vision also changes what can feed a twin, because a camera can become a sensor and turn real activity into state without instrumenting everything. That is the pattern behind computer vision products and behind Raqts, a responsive racquet-sport wall we build the software for, where a vision pipeline reads live play and the system reacts in real time.
What AI does not fix is the physical and organizational half. It cannot make a bad scan accurate, it cannot invent an interface into a control system that has none, and it will not decide who owns keeping the model current. Those stay the critical path, and building faster only helps if the time saved goes into them.
How to scope one without buying a science project
The pattern that works, and what to expect from anyone competent:
- Name one decision and one person who makes it. The twin exists to change that decision. Everything else is scope you can add later.
- Take the smallest physical envelope that contains it. One building, one line, one asset. Site-wide is a phase two conclusion, not a phase one plan.
- Bind one or two live feeds, properly. Including what the system shows when a feed goes stale.
- Ship it on one surface. The one where the decision is actually made.
- Agree the update path in writing, with a named owner, before launch rather than after the first divergence.
- Check whether behavior changed. If the people it was built for stopped opening it after a month, expanding it will not help.
Buyer checklist
Ask these before you sign. The answers separate teams who have run a twin in production from teams who have made a very good video.
- What are you capturing from, at what accuracy, and who pays for the capture?
- Which live systems will this bind to, and have you seen their interfaces yet? An assumption here is the most common source of overrun.
- What does the twin display when a data feed stops? Expect a specific answer about staleness, not reassurance.
- What tolerance does the geometry need, and which decision sets it?
- How does a change in the real world become a change in the twin, who owns that, and how long does it take?
- Which surface is primary, and what exactly is reduced on the others?
- Who receives the source files and project, not just the deployed app? Twins outlive vendors, and yours should be portable.
A digital twin is not a 3D model of your business. It is a decision-support system that happens to be shaped like your building, and it is worth exactly as much as the decisions it changes. Get the capture, the data binding, the tolerance and the update path right, and the visual layer is the straightforward part. Get them wrong and you will own a beautiful, confidently inaccurate model of somewhere that no longer exists.
Null Studio builds spatial and immersive software end to end, from ERIS XR for emergency response and location-based AR with live data feeds to the integrations and interfaces that sit underneath them. Book a demo and we will tell you honestly whether you need a twin, a 3D model, or a dashboard that costs a fraction of both. See our work: ARCortex, Nystag, Raqts and more, alongside our AI and custom software builds.