What to automate first in a contracting business

Ask a contractor what they'd automate first and you'll almost always get the same answer: the paperwork they hate. Usually billing. Sometimes the safety binder. Occasionally the phone.

It's the wrong answer, and it's wrong in a specific, expensive way. The task you hate is the one you're most likely to already be doing carefully — precisely because you hate it and you know it bites. You've built a grudging little ritual around it. It's slow and miserable, but it works.

The money isn't there. The money is in the handoffs.

Why handoffs are where it actually hurts

A handoff is any moment work changes hands: field to office, estimator to PM, PM to billing, you to your foreman, foreman to the crew that shows up Monday. Every one of them is a place where information has to survive a transfer — and most contracting businesses transfer it through memory, a text message, or a conversation in a truck.

When a task is slow, you lose hours. When a handoff fails, you lose the job's margin. Those aren't the same size of problem:

• A change order discussed on site and never written down. Nobody bills it. That's not an hour, that's the change order.
• A material substitution the estimator knew about and the PM didn't. The wrong thing shows up. Now you're paying for a restock, a return trip, and a day of crew standing around.
• A daily report that exists in someone's head until Friday. By the time it's written, the detail that mattered is gone, and so is your ability to back up a delay claim.
• A punch item told to a foreman in a parking lot. It gets done or it doesn't, and you find out at closeout.

None of these feel like automation problems. They feel like people problems — somebody dropped the ball. That's exactly why they persist. You can't fix a systemic handoff failure by asking people to try harder, and every owner reading this has already tried.

How to find yours: the Friday test

Here's the exercise. It takes about twenty minutes and you should do it with a pen, not in your head.

Think back over the last month and list every time you had to go find out something that someone in your company already knew. Not things nobody knew — things that existed, in someone's head or phone or truck, that you had to go chase.

That list is your automation backlog, ranked by how often each one repeats. The top of it is where you start.

It works because it filters for the right thing. You're not looking for slow work — you're looking for information that exists but doesn't travel. That's the class of problem software is genuinely, boringly excellent at, and it's the class where a small fix compounds: once the information moves on its own, every downstream decision gets made earlier.

Four questions before you automate anything

Once you've got a candidate, run it through these. If you can't answer all four, it's not ready, and building it anyway is how contractors end up with expensive software nobody opens.

1. Does it happen at least weekly? Automating something quarterly is almost never worth it. The maintenance cost of a system is roughly fixed; the payback scales with frequency. Weekly is the floor.

2. Can you describe the rule in one sentence? "When a daily report is submitted with an equipment-down note, text me and the mechanic." If it takes a paragraph and three exceptions, the process isn't stable enough to automate yet. Stabilize it as a habit first.

3. Who gets told when it breaks? Automation that fails silently is worse than no automation, because you stop checking. This is the one everybody skips, and it's the one that turns a helpful system into a liability. Name the person and the channel before you build.

4. What happens to the old way? If the clipboard stays on the truck, the crew will use the clipboard. Half-migrated processes are the most common way this fails — you end up maintaining two systems and trusting neither.

Start smaller than feels serious

The instinct with a real problem is to solve all of it. Resist it. The right first automation is one you can stand up in days and judge within a month — one leaky handoff, closed.

There are two reasons for that, and only one of them is about risk. The obvious one: a small system that fails costs you a week, not a year. The better one: you don't actually know what you need yet. Nobody does at the start. The first automation's real job is to teach you what the second one should be, and you can't learn that from a requirements document. You learn it from watching a real one run in your real business for thirty days.

We build our own software this way, and we sell it the same way. One system, proven, then the next. A contractor who has automated one handoff and watched it hold for a month is in a completely different position than one who bought a platform — they know what the thing actually does when a job goes sideways.

That's the whole method. Find the information that exists but doesn't travel. Fix the one that repeats most. Make sure somebody gets told when it breaks. Then go find the next one.