Capture plus delivery: why a scan on its own is not the product

A scan on its own is not the product. Boundless captures the environment and builds the branded platform the client runs it through, so what a client ends up owning is a working tool their teams use, not a file they receive and then have to find a use for. The reality-capture market mostly splits into two camps, vendors who sell the scan and vendors who sell the software, and we sit deliberately across both.

That is the whole argument of this piece, so it is worth being plain about why the split matters and where each half falls short on its own.

A scan is a measurement. A platform is something people use. Confusing the two is the most common way a reality-capture project disappoints the person who paid for it.

The industry itself is fairly clear on this when you read past the marketing. Esri's imagery team put it bluntly: a mesh, point cloud or ortho is a powerful deliverable, but a digital twin is an evolving capability built over time by connecting visual data, systems, analytics, and workflows to support ongoing outcomes. In other words, the file is the start, not the finish.

You see the same distinction drawn across the sector. One vendor glossary defines a visual twin as a live visual representation of a facility, built from 3D scan data, and the foundation of the digital twin journey rather than the destination. The language varies. The underlying point does not. Geometry is where the value can begin, not where it lands.

Because a file has to land somewhere, and someone has to run it. When the deliverable is a point cloud or a set of exports, the client inherits a job they did not ask for: hosting it, giving the right people access, keeping it current, and turning it into something a non-specialist can actually navigate.

Read the standard reality-capture handover and you can see the workload being passed downstream. Matterport's own guidance describes exporting scan data so files import into AutoCAD, Autodesk Revit and countless others. That is genuinely useful for a survey team. It is not useful for a facilities lead, a marketing team or a group of new starters, none of whom own Revit or want to.

The honest version of the reality-capture services pitch is that the technician scans your space and hands back assets. Matterport describe exactly this: capture services provided by expert technicians who scan your spaces for you, providing complete marketing assets in 24 to 48 hours. Fast, clean, and then it is yours to do something with. The doing-something-with is the part that quietly decides whether the money was well spent.

It means we own both halves. We capture the environment using the right tool for the space, and we build the branded, hosted platform the organisation runs that capture through. The output is a product a client operates, with their name on it, their structure, their content sitting on top of the geometry.

That second half is the work most capture vendors do not do and most platform vendors cannot, because the platform vendors never held the scanner and the scanning services never built software. We treat capture methods, 360, drone, LiDAR and Matterport, as inputs to that platform rather than as the thing we sell. The sector broadly agrees this is how capture should feed a twin. As one guide puts it, capture outputs feed directly into digital twin platforms, GIS systems and BIM workflows. We just take responsibility for the whole chain rather than dropping the file at the point where it gets hard.

The practical difference for a buyer is ownership. You are not commissioning a scan and then commissioning a separate developer to make it usable, and then a third party to host it. You commission one thing that arrives working.

Hammerson is a client, and the work is a good illustration of the difference between a scan and a product. The starting point is a captured environment. The thing the client actually runs is a branded platform built on top of it, an experience their audiences move through rather than a dataset their surveyors open.

The reason this matters is that a shopping-centre or property owner does not want a point cloud. They want something a leasing team can show a prospective tenant, something a marketing team can put in front of the public, something that carries the brand rather than the file format. That is a delivery problem as much as a capture one, and it is the half of the job that decides whether anyone outside the survey team ever opens the thing.

I am keeping the specifics of that engagement out of this post deliberately, because the numbers and internal detail are Hammerson's to share, not ours. The point that stands publicly is the shape of it: capture went in, a platform came out, and the client operates the platform.

Because the seams between vendors are where projects rot. When one company scans, another builds and a third hosts, every handover is a chance for the intent to get lost, and the client becomes the systems integrator by accident.

The sector's own commentary keeps circling this. Esri's team warn that organisations who start with technology rather than outcomes often introduce unnecessary complexity and risk, delaying time to value, and add that a baseline is most valuable when it is maintained. Both of those failure modes come from treating the scan as the deliverable. Start from the outcome, own the delivery, keep it current, and the technology choices fall out of that rather than leading it.

Owning both halves also means we can be honest about scope. Sometimes a client genuinely does just need a scan and an export into their existing tools, and in that case a dedicated capture service or an off-the-shelf platform is the right and cheaper answer, and we will say so. Capture plus delivery earns its keep when the environment has to become a tool that non-specialists use, under a brand, maintained over time. If that is not the job, you do not need us for it.

If all you need is survey-grade geometry to check a model against, buy the scan. Matterport, Leica and the specialist capture bureaus do that well, and the file dropping into your BIM workflow is exactly the outcome you want. Wrapping a platform around it would be cost you do not need.

If you already run a spatial-data platform and simply need it fed, you need a capture supplier, not a studio. The case for capture plus delivery is specific: it is for the organisation that wants the captured environment to become something its own people, or its customers, actually use, without becoming a software company to get there. That is the gap we were built to close, and it is the one thing in this market that competitors, split cleanly into scanners and software houses, are not set up to do.