Why Generic Inspection Apps Fail on Construction Sites

Search for construction inspection software and you'll get a decent list of products. Open their demo videos and you'll notice something: one is checking whether a hotel lobby meets brand standards, one is confirming a restroom door frame is secure, one is inspecting the floor of a burger restaurant.

These are competent products. Some are genuinely excellent. They rank for construction terms because they publish more, and better, than most construction vendors do — which is fair enough, and mildly embarrassing for our industry.

But the reason they don't stick on site isn't vocabulary, and it isn't the wording on the checklist. It's that inspection software has largely been built for one half of a project at a time. Either it's a field tool that captures beautifully and tells the office nothing, or it's an office system nobody on the deck will open with gloves on. Construction needs one record that both halves work from, and that turns out to be three separate structural problems.

Gap one: what the inspection is attached to

Every inspection tool attaches results to something, and that anchor decides what the result can do afterwards.

Facilities and hospitality tools anchor to a location hierarchy — region, site, building, floor, room. That's correct for their world, where the location is the unit of work. Store 214's restroom exists permanently and gets checked on a cycle.

Construction doesn't work like that. A site is a sequence of activities that each happen once, in an order, with dependencies. Level 20's slab isn't a place you revisit quarterly. It's a pour that happens on a date, after the rebar is approved, before three other activities can start.

So when a tool records a failure at "Level 20 — Elevated Slab", it has captured a coordinate. Useful for finding it again — but not the thing that matters commercially, which is which piece of work is now held, and what was waiting behind it.

That's why we scope an inspection to the work breakdown structure item — 2.1.2 Mat foundation concrete pour — rather than to a location alone. A location is a coordinate. A work-breakdown item is a scheduled activity with a predecessor, a successor, a subcontractor and a date.

Enlarge

Gap two: what happens when someone presses Fail

In most tools, marking an item failed sets a value. The row turns red, you can add a note if you feel like it, and the failure waits in a PDF for someone to notice.

On site, "fail" isn't a value. It's the most consequential thing an inspector does all day, and it's the one moment where software should get harder to use, not easier. So when an inspector marks Fail in our Construction Hub, the item stops behaving like a form field: the notes box becomes a required remark, the item demands the specific evidence type it was authored for — photograph, document or measurement — a required test result blocks the verdict until there's an actual reading, and a tracked issue can be raised carrying its own lifecycle. The save button changes to Confirm Failure, because at that point it isn't a save.

This is also where an inspection and test plan stops being a document and becomes a system. An ITP's premise is a measured value against a named standard — 28-day strength, cover depth, torque — at a defined hold point. A tool whose richest numeric input is a 1-to-10 slider can express an opinion about quality. It can't express a reading against a spec clause.

Gap three: whether the office ever finds out

This is the gap nobody puts on a comparison page, and it's the one that quietly forces teams onto three tools.

Here's the pattern. The field gets a good mobile inspection app — fast, offline, easy for a site engineer to use in the rain. The office runs something else entirely: a project system, a programme in Primavera or MS Project, a folder of client reports. The inspection app produces PDFs. Someone exports them, someone else files them, and a third person retypes the findings into whatever the head office actually looks at on Monday.

So the QA manager's real question — how many pours failed on Tower B this month, and how many are still open — is answered by opening a folder and counting. The information exists. It just doesn't exist anywhere you can ask a question of.

The tools aren't badly built. They were scoped to one side. A facilities inspection app has no reason to know what a programme is, so it stops at "here is your completed audit". Meanwhile the systems that do model construction properly were built for the office first, and their field experience shows it.

What we've tried to do is make the office's view a consequence of the field's work rather than a re-entry of it. Concretely: the inspection is the same record for everyone. A project engineer can open a pre-pour while the inspector is still standing on the deck and see which items are done, whose turn it is in the sign-off chain, and what evidence has been attached — not a status someone typed, the actual run.

And when an item fails and raises an issue, that issue is what the office already tracks. Open issues, issues by priority, the resolution funnel, the quality dimension of a project's health — these are the office's existing furniture, and a failed inspection populates them without anyone re-keying anything.

The register itself does the rest: filter by whether an inspection is linked to the work breakdown or standalone, see whose turn each one is sitting on, and answer "what's open on Tower B" without opening a folder.

The trade-off buyers are actually being asked to make

Once you've looked at enough of these, the market resolves into an unhappy choice.

The construction-native tools know what an RFI is. They have submittals, drawings, a real project model. They also mostly grew up as desktop software with a mobile app added later, and the seams show — dense screens, deep menus, and inspection flows that were fitted into an object that already existed rather than designed as inspections.

Fieldwire is the sharpest illustration, and I want to be careful here because it's a good product. It's construction-native, Hilti-owned, its plan viewer is fast, and its mobile offline support is genuinely first-rate — better than plenty of tools that market harder about it. Anyone telling you Fieldwire is weak in the field hasn't used it.

But you don't inspect a pour in Fieldwire. You create a task, staple a checklist to it, and tick items — and in their own documentation those items are "complete (tick), incomplete (cross), or not applicable (hyphen)". There's no fail. That's not a visual-design complaint; it's an object-model one, and it's why photos attach to the parent task rather than the line that failed, and why their guidance on finding a defect is to "just create a task for it" by hand. The interface is fine. It's describing the wrong noun.

Enlarge

The well-designed tools don't know what a project is. The best execution experience in this category belongs to a safety-and-facilities platform, and it's genuinely nicer to use than anything a construction vendor ships. It also has no work breakdown, no submittal, no ball-in-court, and its construction story is a connector to somebody else's platform.

Neither half is a bad product. But if you pick one, you buy the other's gap — and most teams end up buying both, plus a spreadsheet to reconcile them.

What to ask in the demo

Four questions, none of which are answered by a feature grid:

1. What is an inspection attached to — a room, a pin, or the activity in the programme?
2. Fail an item, then ask what else in the system now knows. Not "can I export a report" — what changed.
3. Ask what the office sees, live. If the answer involves the word "export", the office is reading history, not status.
4. Fail the same item twice. If round two is a new blank form rather than a second cycle on the same record, you don't have an inspection register. You have a folder of PDFs with a naming convention.

We built Inspections around those answers: scope linked to the work breakdown, a fail that escalates rather than records, one record the field and the office both work from, and re-inspection as a numbered cycle on the same record — with what carries into the next cycle configurable separately for each party, so the contractor redoing the work starts clean while the consultant only re-judges what actually failed.

If you want to see that on a real pre-pour rather than a hotel lobby, book a demo and bring one of your own ITPs — it's a much better test than letting us choose the example.

And if you're not ready to talk to anyone, our free inspection checklists run pass/fail/N-A on a phone with no account, across concrete, structural steel, MEP, electrical and waterproofing. They won't close any of the three gaps above. They will at least stop the checklist getting printed.