Why a construction guy builds AI software instead of buying it

People ask me this a lot, usually with a slightly puzzled look. You ran construction programs for twenty years. Why are you writing software? Wouldn’t it be easier to buy something?

The short answer is that I tried. The longer answer is this post.

The tools weren’t built by anyone who’d done the work

Over two decades I watched a lot of software get sold into this industry. Some of it was technically impressive. Almost all of it was wrong about what a day on a jobsite actually looks like.

The tell is always the same. The software assumes someone has time to feed it. Enter the data. Update the status. Keep the schedule current. Log the change order in the system before you go home.

On a big program, there’s a person for that. On a five-man crew, that person does not exist. The owner is on the tools half the day and on the phone the other half. The foreman has a truck, a phone, and one bar of signal. Every hour spent maintaining the tool is an hour taken from the work the tool was supposed to protect.

So the software gets installed, used for two weeks, and quietly abandoned. Then the next vendor comes through with a nicer demo, and the cycle repeats. I’ve seen it happen at a $500 million program and I’ve seen it happen at a two-truck remodeler. The scale changes; the failure doesn’t.

The demo is not the job

Here’s what a demo looks like: a clean laptop, a sample project with tidy data, a presenter who knows exactly which buttons to press. Everything loads instantly. Every field is filled in.

Here’s what the job looks like: 6am, a concrete truck that may or may not be coming, a sub who didn’t show, an inspector at 10, a homeowner texting about a change she mentioned last Tuesday to someone who may have been the electrician. The plans are a PDF on your phone. The schedule is in your head. The budget is in a spreadsheet you last opened in March.

Software built for the demo will always lose to the job. Not because the software is bad. Because it was designed by people who’d never had to find out whether the concrete was coming.

What we build on instead

We started DVC Apps on the opposite set of assumptions.

Nobody has spare time. If a feature needs someone to sit down and maintain it, it will not get maintained. So the tool has to capture information as a byproduct of work that was going to happen anyway. A photo. A voice note. A tap.

The phone is the only computer on site. Not a tablet, not a laptop, not the office desktop. A phone, held in one hand, with gloves on, outside. Every screen has to work under those conditions or it doesn’t ship.

If it needs training, it has already failed. A contractor will give a new app about ninety seconds. If it isn’t obvious in ninety seconds what to do and why it’s worth doing, it gets deleted. We treat that ninety seconds as the real onboarding budget.

Those three rules shaped Project Proctor, our jobsite management app, and they shaped Estim8 Pro, our estimating app. They’re also why both products lean so hard on AI. Not because AI is fashionable. Because AI is the first technology that can meet the mess where it is. It can read a plan set you photographed on a truck hood. It can take a job described out loud and return quantities. It doesn’t need the industry to get organized first.

Why construction, specifically

The honest reason isn’t that construction is a big market, though it is. It’s that construction is the one industry I know well enough to tell when a product is lying about how the job works.

That’s a rarer skill than it sounds. A lot of very smart people are building AI tools right now, and a lot of them are pointing those tools at industries they’ve read about but never worked in. The output looks plausible. It’s usually wrong in ways only someone who’s stood on the site would catch. The takeoff that counts the drywall and forgets the mud and tape. The schedule that assumes the inspector comes when scheduled. The estimate that uses a national average for lumber in a market where lumber costs 30% more.

I can catch those. I’ve made those mistakes personally, on real jobs, and paid for them. That’s the whole value I bring to the software side. Not the code. The knowing.

What that means for you

If you’re a contractor deciding whether to try any of this, here’s the filter I’d use: was this built by someone who’s done your job? Not consulted with. Not interviewed. Done.

If the answer is yes, the product will probably still have rough edges, but the rough edges will be in the right places. It’ll understand what you actually need to get done before you get home.

If the answer is no, be careful. The demo will be great.