
Construction doesn't have a skill problem. It has an information problem.
Justin Van Wie
•
Nearly every disaster I’ve watched on a jobsite looked like a construction failure and turned out, on inspection, to be an information failure.
I want to walk through a few, because the distinction matters more than it sounds, and because it tells you exactly what kind of tool actually helps.
Three failures that weren’t what they looked like
The wrong material shows up. Two hundred sheets of half-inch drywall delivered to a job that specified five-eighths for the ceilings. Looks like a supplier screw-up, or a careless order. But somebody had the right spec. It was in the plans, on a sheet the person placing the order hadn’t looked at, because they were working from a text message that said ‘drywall for the Henderson job.’
A framer builds out the wrong unit. Two days of labor on a layout that had been revised. Looks like a framer who didn’t read the drawings. But the revision existed. It had been communicated, verbally, in a loud place, on a Tuesday, to a foreman who was thinking about something else. The instruction was given. It just didn’t land.
A change order nobody can invoice. The homeowner asked for the upgraded tile, the contractor said yes, the tile went in, and at the end of the job there’s a $3,000 line item the client doesn’t remember agreeing to. Looks like a contract dispute. It was approved. Out loud. In a driveway. And never written down.
None of those are skill problems. Nobody involved was bad at their job. The drywall supplier delivered what was ordered. The framer built what he was told. The contractor did the work the client asked for. In every case, the information existed somewhere in the business and failed to arrive where it was needed before the moment it mattered.
Why the distinction matters
If those were skill problems, the fix would be training. Better framers, more careful orderers, sharper contractors.
If they were effort problems, the fix would be more people. An office manager to catch the spec. A second foreman to relay the revision. Someone to follow the owner around writing things down.
But they’re neither. They’re routing problems. A fact that already exists in your business, failing to reach the right person at the right time. And routing problems don’t get fixed by training or headcount. They get fixed by changing where information lives and how it moves.
This is the part I want to be precise about, because it’s where the AI conversation in construction usually goes wrong.
What the technology is actually good at
Most AI marketing in this industry makes claims I wouldn’t defend. It’ll optimize your schedule. It’ll predict delays. It’ll make your estimates more accurate than an experienced estimator. Some of that might be true someday. Most of it is a demo.
Here’s the claim I’d defend: routing information is the one thing this technology is unambiguously good at.
Not judgment. It can’t tell you whether the client is going to be trouble.
Not craft. It can’t hang the door.
Not knowing. It doesn’t know what’s behind the wall.
Just making sure what’s already known shows up where it’s needed. The spec on the plans reaching the person placing the order. The revision reaching the framer in a form he can look at, not a form he has to remember. The change order captured at the moment it’s approved, in the driveway, from a phone, instead of reconstructed from memory three weeks later.
That’s a much narrower claim than the industry usually makes. It’s also the only one I’d put my name to.
What this looks like in practice
When we built Project Proctor, the design rule that came out of this was simple: capture information as a byproduct of work that was going to happen anyway.
The crew takes a photo of the framing before drywall goes up, because they were going to anyway. Now it’s in the project record, timestamped, visible to the owner and the client. The change gets approved by a tap on a phone in the driveway, because the owner was standing there with a phone anyway. Now it’s written down. The sub marks the job done because he was going to text someone anyway. Now everyone knows.
None of that requires anyone to sit at a desk. None of it requires training. It just moves the place where information is captured from ‘someone’s memory’ to ‘somewhere it can be found.’
The bar to clear
If you’re evaluating any construction software, here’s the test I’d suggest: does it make information arrive, or does it make information work?
If it needs someone to type things in, maintain it, keep it current, it’s making information work. It’ll get abandoned inside a month, and it should.
If it captures what’s already happening and routes it to the person who needs it, it’s making information arrive. That’s the whole job. Everything else is a demo.
Next post: the line I’d draw between what to automate and what to never, ever automate.