Digital Twins: What They Are and How to Evaluate One
A digital twin is a digital representation of a physical asset kept current by data from the thing it represents. Remove the data connection and it is a 3D model, accurate on the day it was made and less accurate every day after. Four different products are sold under the one word, and they have different costs, suppliers and failure modes.
In short:
- What it is: A representation of a physical asset, facility or system, connected to data from that asset so it reflects current state.
- What it is not: Necessarily live. Most things sold as digital twins are modelled environments with no data connection, which is a content deliverable rather than an operational system.
- What decides the shortlist: What the supplier actually delivers, what the twin connects to after handover, named client evidence and what the buyer owns and can maintain.
- What we could not verify: Headcount, project counts and pricing for most suppliers in this category. See what is documented and what is not.
What a digital twin is
A digital twin is a digital representation of a physical asset, facility or system, kept current by data flowing from the thing it represents. The data connection is the distinction that matters. Without it the artefact is a 3D model, which is a useful thing to own and a different thing to buy.
Three conditions have to hold before the label is accurate. The physical counterpart has to exist, which rules out a concept model of a facility nobody has built. Data has to reach the model on some defined cadence, whether that is a live sensor feed or an annual rescan. And someone has to be using it to decide something, because a representation nobody consults is an archive rather than a twin.
The term is used far more loosely than that in practice, which is why the useful procurement question is never "do you build digital twins" but "which of the four products are you quoting for".
Cintoo works from reality capture, turning laser scan data into environments that can be measured and compared against earlier scans. That comparison capability is the practical dividing line between a model you look at and a model you check things against.
What gets called a digital twin and is not
Four adjacent things are routinely sold under the same word. Telling them apart is the single most useful skill in this category, because the price difference between them is a multiple rather than a margin.
A digital shadow is the one most often mislabelled. It receives data and displays it, which looks identical to a twin in a demonstration. The difference shows up when someone wants to test a change before making it, because a shadow reports and a twin lets you ask questions of the model.
None of the four is inferior. A 3D model is the right purchase for a great many requirements, and buying a live twin when a model would serve wastes money on integration nobody will use.
The four kinds of digital twin
Within the twin label proper, four products are sold, and each has a different cost shape.
Modelled environments
A modelled environment is an accurate 3D representation of a facility, navigable and often visually impressive, with no live data behind it. It is the most common purchase in this category and complete when it ships.
Prevu3D turns reality capture into editable environments, and its model assumes recurring capture rather than a single commissioned build. That assumption is the thing to check, because it determines whether year two has a budget line.
Live twins
A live twin connects a model to operational data so it reflects current state. It is an operational system with hosting, integration and maintenance costs that continue for as long as it runs.
The engineering question is how data arrives, not how the model looks. TechViz works on real-time collaborative visualisation of CAD data, which sits adjacent to this and is frequently bought alongside it.
Simulation twins
Simulation twins predict behaviour rather than report it. They are used to test how a design or system responds to conditions that would be expensive or dangerous to create, and their credibility rests on model validation rather than visual fidelity.
LS Group runs physics simulation among its divisions, and validation evidence rather than rendering quality is the thing to ask about.
Construction twins
Construction twins record what was actually built. They exist because a BIM model is design intent, and the building that results differs from it through site conditions, substitutions and clashes resolved on the fly.
A twin handed over without verification against reality is design intent wearing a twin's name, and its errors stay invisible until they are expensive.
The four kinds compared
These are not a maturity ladder. A modelled environment is not an unfinished live twin, and the most expensive mistake in this category is treating the rows as stages to progress through rather than products to choose between.
The row that catches people out is "complete at". A live twin is never finished, in the same sense that a database is never finished. Budgeting it as a project with an end date rather than a system with a running cost is the most common way a well-built twin is abandoned two years later, and it is a finance decision rather than a technical one.
What the work actually involves
Three streams of work, running in parallel, and only one of them is what buyers picture when they commission a twin.
Capture and modelling produces the geometry. It is the visible part, the part that demonstrates well and usually the most predictable to estimate. Reality capture of a working facility costs more than modelling from design files, because access windows rather than processing time set the schedule.
Integration connects the model to data. It is the least visible and the most likely to overrun, because it depends on systems the twin supplier does not control and often cannot see until the project starts. A supplier who has integrated with your historian or building management system before has solved a problem that a supplier with excellent visuals has not begun.
Interface is what anyone actually judges. Most of a twin budget goes into modelling and data plumbing, all of which is invisible, and what gets evaluated is the screen. A programme with excellent data and a poor interface will be described as a failure. That is not an argument for style over substance. It is an argument for funding the interface deliberately rather than treating it as the last task before handover.
Interactive twins are generally built in Unity or Unreal Engine, while engineering and construction work more often sits on Autodesk or Siemens platforms. Reality capture data usually passes through a specialist tool such as Matterport or Cintoo before reaching either.
The first question is whether a game engine is needed at all. If the job is to view a model, measure it, check a clash or read live sensor values, engineering and reality capture software does that natively, with accuracy guarantees an engine does not provide. Engines earn their place when the twin has to be experienced rather than inspected: walked at scale, rendered convincingly, operated by someone untrained or delivered to a headset.
Who actually supplies digital twins
Three kinds of company sell into this market, and they are routinely compared against each other as though they were the same purchase. They are not, and knowing which kind you are talking to explains most of the variance between quotes.
Platform vendors sell tooling and expect you or a partner to build on it. Autodesk, Siemens, Dassault Systèmes and PTC sit here, as does Azure Digital Twins on the infrastructure side. The economics are licence-based, the capability is broad and shallow relative to your specific facility, and the gap between what the platform can do and what your twin does is filled by implementation work that someone has to fund.
Reality capture specialists sell the pipeline from physical space to usable model. Cintoo, Prevu3D and Matterport work here. Their model usually assumes recurring capture, which aligns their commercial interest with the thing that most often kills twins, namely geometry drift. That alignment is worth more than it sounds.
Custom studios build an application to your specification. Treeview, LS Group, Toobler, Vection Technologies and Digital Twin Studios sit in this group. You get something shaped to your requirement rather than to a product roadmap, at higher unit cost and with ownership terms that vary enormously between suppliers.
Most substantial programmes end up using all three. A capture specialist produces the geometry, a platform holds the data and a studio builds the interface people actually open. A proposal from any one of them that claims to cover the whole job is worth probing, because the parts they are weakest at are the parts that get quietly descoped.
Why the word means so many things
The looseness is not accidental. "Digital twin" arrived as an engineering concept describing a live, bidirectional coupling between a physical asset and its model, and it was adopted as a marketing term by every vendor with a 3D asset to sell. Nothing forces a supplier to mean the engineering definition, and the broader usage is now genuinely established rather than simply wrong.
The practical consequence is that the word carries no information in a sales conversation. Every question that matters has to be asked in other terms: what data reaches the model, on what cadence and what decision does someone make from it. A supplier who answers those three crisply is describing an operational system whatever they call it, and one who redirects to visual quality is describing a content deliverable whatever they call it.
This is also why comparing quotes on the word alone produces such wide spreads. Two suppliers quoting "a digital twin of your plant" can honestly differ by an order of magnitude, because they are quoting for different products.
Where digital twin work divides
Five distinct purchases, each with its own supplier set and its own ranked list.
Custom twin development
Custom covers four different deliverables, which is why the word does so much work in vendor material. Best companies for custom digital twin development unpacks them and ranks the suppliers building to order.
Digital Twin Studios and Toobler both work in this space, alongside Vection Technologies whose focus is making existing CAD and BIM usable across engineering and field teams.
Real-time IoT visualisation
Best companies for real-time IoT digital twin visualization covers the live data case, and it carries a correction worth repeating. Two of its five entries are products rather than companies, and one name that circulates in this category, Velotic ThingWorx, does not correspond to a real vendor. ThingWorx is a PTC product, and that list records PTC in the slot because contracting with a company that does not exist is not possible.
Data visualisation
Best companies for digital twin data visualization ranks by what is being visualised, whether it connects to live data or a static model, who the intended reader is and what evidence each supplier publishes.
Game engine builds
Best companies building digital twins on Unity and Unreal ranks on published evidence of engine work, how source data reaches the engine and what the buyer owns at the end.
BIM and construction
Best companies for BIM and construction digital twins ranks on how each supplier handles the gap between designed and built, what the twin connects to after construction ends and who is expected to operate it.
Digital twins by industry
The same four products appear across sectors, but the buyer, the decision and the evidence standard change.
Energy and utilities buys twins for outage planning and remote inspection of assets that are expensive or hazardous to visit. Best digital twin platforms and development companies for energy covers that market, where the twin frequently sits alongside virtual site tours of energy facilities.
Manufacturing buys for line planning, changeover rehearsal and maintenance. The decision is usually about downtime, which is already costed, making the business case easier to defend than in most sectors.
Construction and AEC buys to verify built against designed and to hand something usable to the operator. Its structural difficulty is the handover cliff, covered below.
Healthcare uses the term differently. A human digital twin is a computational model of a patient or population used to simulate a device or therapy before human testing, and the suppliers come from life sciences rather than from facility modelling.
Industrial operations more broadly buys for access, and the twin often begins as an industrial or factory virtual tour that later acquires a data connection.
What does a digital twin cost?
Published pricing is rare in this category, and the range is wide enough that any single figure would mislead. What can be said usefully is which decisions drive the cost, because those are within a buyer's control in a way the rate card is not.
Access windows are the driver buyers most often overlook. Scanning a plant that runs three shifts is not the same job as scanning an empty warehouse, and the schedule is set by when the supplier is allowed in rather than by how long the scanning takes.
A proposal that prices only the first two rows describes the first year rather than the asset. That is not necessarily dishonest, since it answers the question that was asked, which is why the brief has to ask about the rest.
How long does a digital twin take?
Longer than the modelling, in almost every case, because the constraint is rarely the geometry.
Three things set the critical path. Data access comes first: getting permission and credentials for the systems the twin must read from is an organisational process, not a technical one, and it routinely takes longer than building the connector once access exists. Site access comes second, particularly for operating facilities where capture has to fit around production. Sign-off comes third, because a twin usually crosses engineering, operations and IT, and those three functions rarely share a single approver.
None of the three is the supplier's to solve. The useful proposal-stage question is what the supplier needs from you and when, since the answer reveals whether it has delivered into an organisation like yours before or is estimating from the outside.
What changes between sectors
The four products stay the same across industries. What changes is which one gets bought, who signs for it and what counts as evidence.
Regulated sectors raise the evidence bar rather than the technical one. In energy, pharmaceutical manufacturing and aviation, a twin informing an operational decision may sit inside a compliance regime, which means the model's provenance and update history matter as much as its accuracy. Suppliers who have worked inside those regimes will say so and produce the documentation without being asked.
Asset-heavy sectors buy for downtime, which makes the business case straightforward, since the cost of an unplanned outage is usually already tracked. Asset-light sectors buy for coordination or communication, where the benefit is real but harder to price, and those programmes are more vulnerable at renewal.
The sector that most often mislabels its requirement is property and construction, where a marketing visualisation and an as-built record are both routinely called twins. They have different accuracy requirements, different suppliers and roughly an order of magnitude between their costs.
What buyers get wrong
Five mistakes account for most abandoned twins, and none of them is technical.
Buying a live twin when a model would serve. Integration is the expensive, slow part. Commissioning it for a requirement that is really "let people look at the plant" spends the budget on plumbing nobody uses.
Treating the interface as the last task. The screen is what gets judged. Leaving it to the end means it is built with whatever budget survived integration overruns.
No named decision. A twin bought because the category is prominent has no user who notices when it drifts. That user is the only reliable guarantee a twin stays accurate, because they complain when it stops being.
No geometry update path. A twin represents a facility that changes. A model never recaptured drifts until people stop trusting it, and an untrusted twin stops being opened.
The handover cliff. Capital projects fund construction and end at practical completion, while the twin's value is realised across the decades of operation that follow. Unless an operational owner is named and funded before handover, the twin arrives at a team that did not specify it and has no budget line for it. That team will not maintain it.
The cliff is worth dwelling on because it is structural rather than accidental. The people who commission a construction twin are measured on delivering a building on time and to budget, and the twin helps them do that. The people who would benefit from it for the next thirty years are not in the room when it is specified. Nothing about the technology causes this, and no supplier can fix it. It is solved, when it is solved at all, by naming an operational owner in the project charter and giving them a say in the specification while there is still time to influence it.
A related pattern shows up in facilities that were captured once during a refurbishment. The scan was funded by the refurbishment, the model was accurate the week it was made, and five years later it depicts a layout that no longer exists. Nobody decided to abandon it. The budget that would have refreshed it simply never existed, because the original funding was tied to a project rather than to the asset.
The demonstration problem
Twins demonstrate better than almost any other enterprise software, and that is a hazard rather than a benefit. A well-built demonstration shows a beautiful model, live-looking data and a smooth flythrough, and none of those three is the thing that determines whether the programme survives.
What determines survival is unglamorous: whether the data connection holds when a source system is upgraded, whether anyone recaptures the geometry and whether a named person opens the twin as part of their job. None of that can be shown in a demonstration, which is why buying decisions made primarily on demonstrations have a poor record in this category.
The practical defence is to ask to see a twin the supplier delivered two or more years ago, still in use, and to speak to the person who uses it. A supplier with such a reference will produce it readily. A supplier who can only show recent builds is telling you something about how long their twins stay in service.
What a competent supplier sounds like
Four things separate a supplier who has delivered twins into operating organisations from one who has built impressive demonstrations.
They ask about your data before your geometry. A supplier whose first questions are about historians, building management systems, asset registers and who controls access is working from experience. One whose first questions are about square footage and visual fidelity is scoping a modelling job.
They name the systems they have integrated with. Not "we integrate with IoT platforms" but the specific products, versions and what went wrong. Integration experience is cumulative and specific, and a supplier who has it will volunteer the detail because it is their differentiator.
They raise the update path unprompted. Geometry drift is the failure mode that ends most twins, and a supplier who has watched it happen will bring up recapture before you do. One who lets you sign without discussing it either has not seen the failure or is content to sell you the first year.
They are precise about what you own. Vague answers about IP and source code are not oversights at this stage of a sales process. The suppliers who transfer everything say so plainly, because it is a competitive advantage, and the ones who do not usually have a reason.
A fifth signal is negative. A supplier who agrees that every one of your requirements is straightforward has either not understood them or is not planning to deliver all of them. Twins touch enough systems that a competent supplier will identify at least one thing in your brief that is harder than you think it is.
Questions worth asking in a first call
Five that surface more than a capability deck will.
- Which of the four products are you quoting for, and what would change if we needed a different one?
- Which of our source systems have you connected to before, by name and version?
- Who recaptures the geometry, how often and what does that cost in year two?
- What do we hold at the end: source files, project files, the model or a licence to view it?
- What in this brief is harder than we seem to think it is?
The last one is the most informative. A supplier who cannot answer it has not read the brief closely enough to have an opinion.
What to establish before briefing a supplier
Four answers make proposals comparable. Without them each supplier fills the gaps differently and the quotes cannot be set side by side.
Which of the four products you need. Saying "a digital twin of the plant" invites four honest quotes at four price points. Saying "a measurable as-built model, refreshed annually, no live data in phase one" invites quotes for the same thing.
Which systems it must read from, and whether access exists. Integration effort depends on the age and openness of the source systems, and no supplier can estimate it from a description of the facility.
Who owns it after handover, and have they agreed. This one line prevents the most common failure in the category. It is also the question buyers are least often able to answer at brief stage, which is itself informative.
The refresh expectation, and who performs the recapture. A supplier expecting an annual return quotes differently from one assuming a single engagement, and the difference is an assumption rather than a rate.
What is documented and what is not
This section exists because the gap between what suppliers claim and what a buyer can check is wider in this category than in most.
Usually verifiable from a primary source. Platform and engine support, published named clients, product documentation, integration partners and certification. Suppliers who work with Autodesk, Siemens or Dassault Systèmes platforms are generally listed in those vendors' own partner directories, which is a check a buyer can run in a few minutes.
Usually not verifiable. Headcount, project counts, hourly rates, project minimums and award lists. These figures overwhelmingly originate in third-party directory profile fields that the directory does not audit and the supplier can edit. They appear precise and are not evidence. Where our rankings could not confirm such a figure from the supplier's own site or documentation, it is recorded as Not disclosed rather than repeated.
Frequently contradicted. Ownership terms. Suppliers rarely publish what the buyer holds at the end, and the answer varies more here than in most software categories. Treeview publishes full transfer of IP, source code and assets. Most do not publish terms at all, which means the question belongs in the contract rather than the assumption.
No primary source exists. Market size and growth projections for digital twins circulate widely and trace back to commercial research reports whose methodology is not public. This site does not repeat them. That is a deliberate omission rather than an oversight, and a buyer being shown a market projection in a sales deck is entitled to ask which measurement it rests on.
How the rankings below were built
Every list linked from this page ranks on four published criteria and states what is not a ranking factor. The criteria differ by list because the purchases differ, and each post sets out its own in a section called How this list was built.
Across the digital twin lists, the recurring four are what the supplier actually delivers, what the twin connects to after handover, named client evidence and what the buyer owns and can maintain. Pricing is generally not a ranking factor, because most suppliers in this category do not publish rates, and ranking on a figure only some entries disclose would reward disclosure rather than fit.
The methodology page sets out how entries are assessed across the whole directory.
Where to start
Decide which of the four products you need, then read the list covering it. Each publishes its criteria in full.
- Best companies for custom digital twin development
- Best companies for real-time IoT digital twin visualization
- Best companies for digital twin data visualization
- Best companies building digital twins on Unity and Unreal
- Best companies for BIM and construction digital twins
The directory lists developers, platforms and software with sourced entries, and the energy and healthcare twin lists cover the two sectors where the term means something different.
Frequently Asked Questions (FAQ)
1. What is a digital twin?
A digital twin is a digital representation of a physical asset, facility or system, kept current by data from the thing it represents. In practice the term covers four products: modelled environments, live twins, simulation twins and construction twins.
2. What is the difference between a digital twin and a digital shadow?
A digital shadow receives data from the physical thing and reports its state. A digital twin reflects state and is used to ask questions of the model, such as testing a change before making it. The two look identical in a demonstration and differ in what they let you do.
3. Does a digital twin have to use live data?
No, and most do not. A modelled environment with no data connection is the most commonly purchased form. It is a legitimate product, but it is a content deliverable rather than an operational system, and confusing the two is the main procurement risk in this category.
4. What is the difference between BIM and a digital twin?
A BIM model is design intent, produced to get a building built. A construction digital twin records what was actually built, which differs through site conditions, substitutions and clashes resolved during construction. A twin handed over without that verification is design intent under another name.
5. Why do digital twin projects fail?
Most often because the geometry is never updated, so the model drifts from reality until people stop trusting it. The next most common reasons are that no specific decision was named for the twin to support, and that no operational owner was funded to run it after handover.
6. Can you verify a digital twin supplier's headcount or project count?
Usually not. Those figures generally come from third-party directory profile fields that are self-reported and unaudited. Platform partnerships, published named clients and product documentation are checkable, and are what our rankings use instead.
7. How much does a digital twin cost?
Published pricing is rare and the range is wide, because four different products are sold under the term. The cost drivers within your control are capture method, number and age of the source systems and refresh frequency. A proposal covering only the build describes the first year rather than the asset.
8. Who owns a digital twin after it is built?
It varies more than in most software categories, and most suppliers do not publish terms. Some hand over source files and full IP, some retain the model and licence access back, and some provide a platform on which your team builds. Establish it before signing, because it decides whether year three is a maintenance cost or a rebuild.
