A consultant comes in. They interview your team. They map your processes. They deliver a 30-page report with findings, recommendations, and a prioritized action plan.

Then they leave.

You're holding a document that accurately describes everything that's broken. You agree with every recommendation. And now you need to find someone to actually build the fix — or, more likely, you put the report in a drawer and go back to the same broken workflows because nobody has the bandwidth to implement it.

I've watched this happen enough times to know the diagnosis isn't the hard part. The hard part is building the system that makes the diagnosis irrelevant.

The gap between knowing and doing

Most consulting engagements end at the document. The deliverable is understanding. Here's what's wrong, here's what to fix, good luck.

That made sense when building systems required a development team, a six-figure budget, and months of scoping. The consultant's job was to think. Someone else's job was to build.

That wall is gone.

I can sit with a 3-person nonprofit, map their workflows on Tuesday, and have a working automation deployed by Friday. Not a prototype. Not a spec. A system their team uses Monday morning — donor acknowledgment pipeline, volunteer scheduling engine, board packet generator, grant tracking dashboard. Whatever the assessment reveals they need.

The same person who found the pattern builds the tool. No handoff. No translation layer. No six-month implementation timeline where the original insight gets diluted through three rounds of vendor meetings.

Why this matters now

The barrier to building custom tools has collapsed. Anyone with operational knowledge and access to modern development tools can build purpose-fit software faster than an organization can evaluate, purchase, and configure an off-the-shelf product.

This changes what consulting should look like.

If your consultant can diagnose the problem but can't build the solution, you're paying for half the work. If your developer can build the solution but doesn't understand the operational context, you're building the wrong thing.

The value is in the person who does both.

What this looks like in practice

I run a 120-year-old arts venue with three staff. No departments. No middle management. Every operational challenge — volunteer coordination, donor management, event logistics, grant writing, board reporting — lands on one desk.

Nothing on the shelf fit. Every tool I tried gave me a database and wished me luck.

So I built. Volunteer coordination went from six hours a week to forty-five minutes. Board packet assembly from four hours to one click. Event entries push to five platforms from a single form. Not because the technology is impressive — because the systems are designed around how we actually work.

Now I do the same thing for other organizations. I call the practice Groundwork, because the work that matters is always underneath. I start with a Workflow Assessment — mapping how work actually flows, not the org chart version. When the assessment reveals a systems gap, I build the custom tools to close it. The client keeps the keys. No recurring dependency. No vendor lock-in.

The "just use Notion" problem

Somebody always suggests it. Just use Notion. Or Airtable. Or Monday.com. Or whatever tool promises to be "the everything app."

Those tools are good. I use some of them. But they solve the storage problem, not the workflow problem. Your information has a home — congratulations. Now who's responsible for moving it from one stage to the next? Who gets notified when something falls through? What happens when the person who built the Notion template leaves?

The system isn't the tool. The system is the pattern of work that the tool enables. If you don't design the pattern first, you're just putting a mess in a prettier container.

This is what I mean by operations design. You don't start with the tool. You start with the question: what actually needs to happen here? Then you build the minimum system that makes it happen reliably, every time, without depending on any single person's memory.

What I'm not selling

I'm not selling software subscriptions. I'm not selling ongoing dependency. I'm not selling a platform you have to conform to.

I build the system your operation actually needs — designed around your team, your constraints, your workflows. I hand it over with documentation your team can maintain. If it only works when I'm in the room, it's not done.

Some organizations don't need custom work. They need a solid off-the-shelf tool configured correctly. I have those too — self-serve products built from the same operational patterns. But the flagship is the custom engagement, because that's where the real leverage is.

The question to ask your next consultant

When someone proposes a consulting engagement, ask them: what happens after you hand me the report?

If the answer is "you'll need to find someone to implement it," you're buying half a solution.

If the answer is "I build it, you own it, and your team runs it Monday morning" — that's the whole thing.

The diagnosis and the build shouldn't be separate engagements from separate people. The person who finds the pattern should be the one who builds the tool.

That's what I do. And the organizations I work with don't have a drawer full of unimplemented consulting reports to show for it.