Construction Reality Capture Software: Turning 60,000 Site Photos Into Evidence You Can Bill and Defend

The claim arrives fourteen months after the work

A subcontractor files for delay and disruption on a hospital tower. Their narrative says level 12 east was not released to them until 14 March, six weeks after the contractual date, and that the riser penetrations were not cored when they arrived. Your project executive believes that is wrong. Proving it is another matter. There are roughly 60,000 photographs from that job spread across a document management folder, three superintendents' phones, a weekly 360 capture service and a drone survey vendor's portal. Nobody can produce, in a form that will survive cross examination, an image of that specific location on that specific date with a defensible link to where it was taken.

So the claim gets settled rather than defended, which is what usually happens. The settlement is treated as a cost of doing business. It is actually the cost of not having built a record, and on a job of that size a single settlement typically exceeds the entire cost of a system that would have prevented it.

Capture is solved. Retrieval and inference are not

The market here is real and mature, and it deserves credit. OpenSpace and Matterport turn a walk with a helmet camera into a navigable record aligned to a floor plan. DroneDeploy handles aerial and exterior capture with useful survey grade outputs. Buildots and Disperse go further and infer installation progress from imagery against a schedule. These are good products built by serious teams and for a large number of contractors they are all that is required.

They stop in three predictable places, and those three places are why owners and project executives on the biggest jobs commission builds.

The first is your data model. Their progress inference maps to their activity taxonomy, and your earned value, your cost codes and your subcontract scopes map to yours. The translation between the two is done by a person in a spreadsheet, every month, which is exactly the manual reconciliation the software was bought to remove.

The second is the money. Progress that cannot be tied to a line on the schedule of values does not affect a payment application, and a payment application is where progress actually becomes a business event. Very few capture platforms carry the record all the way into the billing conversation, because billing is contractual and each owner's format differs.

The third is custody. When capture lives in three vendor portals with different retention terms and different export capabilities, your evidence for a claim in 2031 depends on a software company's business decisions in 2029. That is an uncomfortable position for a record whose entire purpose is to be produced years later.

Problem one: an untagged photo is not evidence

The difference between a photo archive and a record is indexing. Every capture needs a resolvable location, meaning a point on a specific drawing revision on a specific level, a timestamp that cannot be quietly edited, a capture device and operator, and a link to whatever was scheduled to be happening there. Without those five things the image proves that something existed somewhere at some point, which is worth very little in a dispute.

A build makes the location the primary key. Captures attach to a spatial reference that persists across drawing revisions, so a photo taken against revision C still resolves when the level is reissued at revision F. That sounds like a detail until you realise that most disputed areas were revised two or three times, and a naive implementation loses the historical alignment every time a new drawing lands.

Problem two: the argument is about quantity, not existence

Disputes are rarely about whether a wall exists. They are about how much of the scope was complete on a given date, because that is what governs both the payment application and the productivity claim. Ninety per cent complete on drywall is a number somebody asserts, somebody else disputes, and nobody can compute.

What a custom build does is bind captures to quantities. Your takeoff already knows there are 4,200 linear feet of stud partition on level 12. If the capture record can be assessed area by area, the completion figure becomes a computation against a known denominator rather than a superintendent's estimate. Where imagery supports automated detection of installed elements, the detection produces a proposed quantity and a human confirms or corrects it. Be sober about what detection can do: it is reliable for large repetitive elements in clear line of sight, weaker for concealed work, work behind stored material and anything in a congested plant room. The honest design is assisted assessment with human confirmation, not autonomous measurement, and any developer promising the latter is selling you a demo.

Problem three: schedule alignment is where the value compounds

A capture record becomes powerful the moment it is linked to schedule activities. Then you can ask the questions that matter: which activities claimed as started have no supporting capture, which areas have been available for six weeks with no work observed, where is the sequence deviating from the plan quietly.

Linking to a scheduling tool is a real integration rather than a checkbox. Schedules get restatused weekly and rebaselined occasionally, activity codes get renamed, and the mapping between an activity and a physical location is not in the schedule at all, because schedulers encode location in activity naming conventions rather than as structured data. A build has to hold a location breakdown structure of its own and map activities onto it, and that mapping is maintained rather than derived once. Contractors who skip this end up with a beautiful capture archive that answers no schedule question.

Problem four: closing the loop into the payment application

Here is where a build stops being a documentation tool and starts being a financial one. Each pay period, every line on the schedule of values gets a claimed percentage. Today that percentage comes from a conversation. With location indexed capture bound to quantities and activities, it comes with an evidence pack attached: the captures supporting the claim, the computed quantity, the delta since last period.

Two things happen when you do that. Owner reviews get faster because the reviewer is checking evidence rather than negotiating a number, and disputed lines shrink because the argument is now about a specific area rather than about a percentage. On the subcontract side the same mechanism works in reverse, letting you assess what a trade actually installed before paying their application. That is the feature that makes the project pay for itself.

Problem five: the record has to outlive the project and the vendor

Claims surface years after completion, and litigation timelines are longer still. Your evidence needs to be exportable in open formats, complete with metadata, and held somewhere your legal team controls. Point clouds should be retained in a standard exchange format rather than only in a proprietary viewer. Images need original files with untouched capture metadata alongside any processed derivative. Every record needs an append only history so nobody can argue the archive was edited after the fact.

This is unglamorous and it is the single strongest argument for owning the system on jobs where litigation is a realistic outcome. Capture platforms are excellent operational tools. They are not designed to be a party's evidence custodian for a decade.

What it costs and how long it takes

A focused first release covering location and date indexed capture ingestion from your existing cameras and vendors, alignment to the drawing set with revision handling, and activity level progress records runs $70,000 to $150,000 and ships in 12 to 18 weeks. A full platform adding point cloud comparison, installed quantity computation per trade, schedule integration, subcontractor assessment and pay application evidence packs runs $180,000 to $450,000 phased over 7 to 12 months.

What drives cost up in this category: point cloud handling, because processing and serving large scan data is genuine infrastructure work rather than a feature. Automated element detection, which is a model development effort with a data collection phase, not an API call. Integration with the scheduling tool and the accounting or billing system, each of which is its own project. And the number of concurrent projects, since multi project deployment changes the architecture from day one.

What keeps cost down: continuing to use commercial capture hardware and services for the capture itself, and building the indexing, inference and money layer on top. There is no reason to build a 360 capture pipeline from scratch when the field crews already have equipment that works.

How to choose a developer

Ask how they will handle drawing revisions. If a capture taken against revision C loses its alignment when revision F is issued, the archive degrades every month and is worthless in year three. This one question separates people who have done this from people who have not.

Ask what happens to a claim in five years. The right answer covers open format export, original files with intact metadata, append only history and an archive you control independently of any running application.

Ask them to be specific about automated detection: which elements, under what conditions, with what human confirmation step, and how accuracy is measured on your own imagery rather than on a marketing dataset. A team that describes the limits honestly is the team you want.

Ask who owns the code, the models and the data, and get it in writing before kickoff. You should own the repository, the infrastructure accounts, any trained model weights and every byte of capture. At Digital Heroes the client owns all of it from the first commit, and on a system built to be evidence, ownership is not a negotiating point.