Nearly every business owner I sit down with tells me some version of the same story. “We’ve run this process for fifteen years. We know what works, where it breaks, and what we’d change if we could. The software doesn’t do that, and the last time we asked, someone quoted us six figures and nine months.”
So they don’t change it. They build workarounds instead; a spreadsheet that started as a stopgap now holds up half the business, and someone on the team spends a good part of their week carrying data between what the software does and what the business needs. Every year the gap gets a bit wider and the workaround a bit more fragile.
I’ve seen it from the other side too. I spent years inside the consulting machine, in rooms where we mapped processes onto whiteboards, turned them into requirements documents, handed those to a development team and waited months for a build. By the time it launched the business had moved on, and we’d delivered an expensive approximation of what someone needed half a year earlier.
That’s the part that has changed. With AI coding tools, a small team (or one person) can get from a clear description to working software in days, sometimes hours. The build used to be the slow, expensive step. Now the slow step is knowing exactly what to build, and you already have that.
Writing it down is the work
There’s a name for working this way: spec-driven development. You write a specification in plain language, saying what the thing should do and where its edges are; an AI coding agent generates the code from it; you review, adjust and go round again. GitHub’s write-up of it calls code “the last mile”, which I think is about right.
So the most valuable thing you bring to this is knowing the work, and technical knowledge comes a long way second. You know where the process breaks because you’ve watched it break for years. You know what ‘good’ looks like. That knowledge - in your head, in your team’s habits, in every workaround you’ve built - is the specification. The workarounds are especially useful, actually; each one is a precise record of something the software should have done and didn’t.
Most of what I do with a client is getting that out of their heads and onto paper, in enough detail that it can be built. Then we build it, and they can see within days whether we got it right.
Piet wrote to me after fifteen years of not hearing from each other. He needed a bit of help with a website project he had in mind. Nine months later it’s a full online family museum, and it’s become something pretty amazing.
The consultant trap
I’ll say something a little uncomfortable for someone in my line of work. The usual big-consultancy pattern runs from discovery workshops to a beautiful strategy document, then enterprise tools and a multi-year implementation, and then they leave. What’s left sort of does what was promised and was behind before it went live. No consultant should walk into your company, turn it upside down, and leave you poorer and more confused than before.
Going without systems isn’t the answer either. You can build what you need now, with the detail only you can give, at a cost and pace that would have sounded made up a few years ago.
Fewer tools, connected properly
Most companies don’t choose their tools so much as collect them; every problem gets its own subscription, and after a few years nobody’s sure what half of them do. I’d rather start the other way round. Keep the tools that do the job and connect them, so data moves without someone copying it by hand. Where nothing fits your process, build the small thing that does, and own it.
The person who knows the business best should decide what gets built. That’s you and the people who’ve been running these processes all along, not a consultant who showed up on Monday or a vendor whose roadmap was never about your business.
If there’s a process you’ve been working around for years, try writing down what it should do in plain sentences, as if you were explaining it to a new colleague. Put the exceptions in too; they’re usually where the current software lets you down.
If this poked at something you're building: talk to me.
MAKE YOUR CASE.