I run my consulting practice on the systems I sell

There’s a test I apply to anyone selling business advice: do they use it themselves? The marketing agency with no marketing. The ops consultant whose own ops are a mess. It’s common enough to be a cliche.

So here’s my own answer to that test. Headwaters Automation is a consulting practice that builds AI and workflow automation for small and mid-sized businesses. It is also, itself, a small business. One operator, a handful of active clients, and no back office. The back office is software. This essay is a walkthrough of what runs my practice while I’m doing client work, what it costs me to maintain, and the one system that quietly failed for two weeks before another system caught it.

The morning briefing

At 8:00 every morning, a briefing lands in my inbox. It reads my project notes, my session logs from the previous day, my calendar, and my task tracker, and it tells me three things: what moved yesterday, what’s stalled, and what today should be about.

I didn’t build this because mornings are hard. I built it because I kept losing the thread between client projects. On any given week I might touch a legal staffing firm’s job pipeline, a restoration consultancy’s website, and a window cleaning franchise’s quoting workflow. The cost of switching between those isn’t the work itself. It’s the twenty minutes of “where was I” every time. The briefing pays that cost once, automatically, before I sit down.

The systems check their own work

This is the part I’d point to if you only read one section.

Every morning, before the briefing goes out, a verification script checks 22 claims against the live systems they describe. Is the client’s newsletter actually scheduled, or does my status file just say it is? Did the blog post actually publish? Is the webhook actually responding? Did the last code change actually deploy?

Each claim gets checked against the real system. Not my notes about the system. The real one.

I built this after catching myself, more than once, reporting something as done because a file said it was done. The file was wrong. Notes drift. Live systems don’t lie. In my experience the single most dangerous artifact in any automated business is a status document nobody verifies.

The guard rails

Some of my automations exist to stop me from doing things.

Before any marketing copy I draft can be saved, a check runs against my own writing rules. Banned buzzwords, punctuation habits I’ve decided against, phrases I’ve retired. If the draft violates the rules, the save is blocked. Not flagged. Blocked.

Twice a week, another routine emails me the three oldest items I’ve left hanging, and any conversation that’s gone quiet for five days. Follow-up is the highest-value work in a consulting practice and it is the first thing that slips when client work gets loud.

None of this is sophisticated. That’s the point. The highest-return automations in my practice are the ones that do one dull thing reliably.

The one that failed

Earlier this summer, one of my routines stopped working. It was the one that processes my meeting notes after client calls and drafts the follow-ups.

The cause was embarrassing in the way real causes usually are: a spending cap. I had set a one-dollar budget limit on the job when I built it, as a safety measure, and a later change pushed the cost per run just past a dollar. The routine didn’t crash. It just started quietly failing, run after run, for about two weeks.

Here’s what matters: I didn’t catch it. An audit did. One of my checks flagged that the routine’s last successful run was two weeks old, and the whole thing unwound from there in an afternoon. Root cause found, cap fixed, and a heartbeat check added so that this class of failure can’t be silent again.

I could have left this story out of the essay. It’s the story I’d most want a prospective client to read. Anyone who sells you automation and doesn’t talk about failure modes is selling you the demo, not the system. Automations fail. The design question is never “will it fail” but “who finds out, and how fast.”

What this costs

Honesty requires the other side of the ledger.

This stack took real time to build, and it takes ongoing attention. Roughly once a month something needs a fix: an API changes, a permission expires, a tool updates underneath me. Two weeks unattended is my bar for calling a system done, and some of mine took three or four attempts to get there.

That maintenance cost is exactly why my client builds are scoped the way they are. Fixed scope, written success criteria, and a handoff that includes the failure alerts, not just the happy path. I learned what to include by paying for the omissions myself first.

Why this matters if you run a business

You don’t need my stack. You need the three lessons it keeps teaching me.

First, automate the switching costs, not just the tasks. The briefing saves me more time than any single automated task does, because it eliminates re-orientation.

Second, never trust a status report you can’t verify against the live system. If your dashboard says “sent” or “done” or “posted”, something should occasionally check whether that’s true.

Third, every automation needs a way to fail loudly. A silent failure is worse than no automation, because you’ve stopped watching.

Most owners I talk to don’t need convincing that automation is worth doing. They just don’t know what’s worth automating or where to start. The honest answer is: start with the thing you’d check every morning anyway, and make sure it can tell you when it breaks.

If you want to see what this looks like mapped onto your own business, I do free 30-minute Mapping Sessions. You walk away with an initial written map of what’s worth automating, what isn’t, and what to do next. No pitch.