Published 31 October 2026
Most construction projects already generate the raw material for progress tracking: site photos, drone flyovers, daily walkthroughs on a phone camera. What’s missing is turning that pile of images into an actual answer to the question a project manager asks every week: are we on schedule, and if not, where exactly are we behind?
Today that answer usually comes from someone walking the site, comparing what they see to the schedule in their head, and reporting a rough percentage. It’s not wrong, exactly, but it’s slow, inconsistent between superintendents, and it happens on a weekly cadence when the underlying photos could support a daily one.
What computer vision actually adds here
The job is not “look at a photo and guess how done the building is.” That framing is too vague to be useful and too vague to be accurate. The job that actually works is narrower and more mechanical: compare photos of the same physical location, taken at different points in time, against a defined set of progress milestones for that location, and flag whether each milestone appears complete, in progress, or not started.
Fixed capture points matter more than fancy models
The single biggest driver of accuracy in this kind of system is not model sophistication — it’s capture consistency. A system comparing photos from the same tripod position or drone waypoint, at a similar angle and time of day, will outperform a far more advanced model trying to reconcile photos taken from random, inconsistent vantage points. Before investing in the vision pipeline, it’s worth investing in a simple, repeatable photo capture routine: the same locations, the same angles, on a regular schedule.
Milestone definitions have to be concrete
“Foundation work” is not a milestone a vision system can check against a photo. “Footings poured and cured, rebar placed for walls” is. The framework schedule needs to be broken into visually verifiable checkpoints — things that are actually visible in a photograph — before a vision system has anything concrete to check against. This decomposition work is usually done once per project type and reused, not redone from scratch every time.
Change detection, not scene description
The most reliable version of this compares a current photo against a prior photo of the same location and asks what changed, rather than trying to fully describe everything in a single image from scratch. Framing the problem as “what’s different here” rather than “what is everything in this photo” tends to produce a more reliable, more specific signal for schedule tracking.
Where this plugs into existing project tools
This isn’t a replacement for your scheduling software — it’s an input to it. The output of the vision pipeline is a structured update per milestone (complete, in progress, not started, with a confidence level and the supporting photo), which gets written into whatever scheduling or project management tool the team already uses, the same way a site visit report would, just faster and more consistent. Pairing this with the broader computer vision development work we do means the capture and detection pipeline is built around your specific site conditions and milestone structure rather than a generic model.
Where this breaks
Weather and lighting are the most common practical failure point — a photo taken in heavy shadow, rain, or at a very different time of day than the baseline can genuinely change what’s visible and produce a false read, which is why confidence scoring matters more than a flat yes/no answer. Occlusion is the second — materials, equipment, or scaffolding blocking the exact area being tracked will read as “no progress visible” even when real progress happened just behind the obstruction, and the system needs to flag that as unclear rather than report it as a setback. Interior work is harder than exterior for the same reason photography is harder indoors generally: more variable lighting, more clutter, and work that is sometimes invisible from any fixed camera position (conduit run inside a wall, for instance) and needs a different tracking method entirely, like checklist-based reporting instead of visual verification.
Where it pays off fastest
This is most valuable on projects with many repeated units needing comparable progress views — multi-building developments, large single structures with distinct zones, or any project where a superintendent is currently spending real time each week manually walking and comparing. Smaller projects, or ones with highly variable, non-repeatable work, often don’t generate enough volume to justify the setup cost of defining milestones and capture routines.
Getting started
The practical starting point is almost never the vision model — it’s agreeing on the milestone checklist and the photo capture routine for your specific project type. Once those exist, the detection pipeline is comparatively straightforward to build. If you’re tracking progress on a tender or active build and want to scope what this would actually look like for your site, our construction and tender AI work covers this directly, or you can reach the team through our contact page.
Related