Work

A Brisbane psychologist was losing hours each week writing diagnosis reports, while a growing backlog of ADHD assessments piled up behind her. She'd built good Google Doc templates that helped, but they exposed just how repetitive the work was. So she'd tried to automate it with AI, got into a tangle she couldn't undo, and came to me to fix the broken scripts.

The scripts weren't the problem. They'd stalled because no one had defined what the automation was actually meant to do. She'd started building before stepping back to map the path, and doing something had felt like progress right up until it became a pile of frustration she couldn't climb out of.

So I did look at the code, but mostly to settle her down; she was wound so tightly about the mess that she couldn't talk me through it clearly. What she needed first was someone to understand the problem, not the script. As I played back the picture I was forming and she saw I genuinely understood the work, her confidence grew and she could finally articulate what the automation needed to do. I narrated every step as I went, so the focus stayed on transferring her knowledge while I handled the technical side, building it properly so it could change over time.

She got 8 to 12 hours back every week, time that went straight back into seeing patients and running her practice instead of wrestling with technology that was never her wheelhouse. She told me more than once how calming the whole thing had been. I've heard that before. Clarity of thought tends to make a lot of things work better, and that, more than the code, is what I'm actually there to provide.

A business development manager at an ISO certification firm asked whether technology could help him find sales leads. The information he needed was sitting in online directories, which businesses held which certifications, and when they were due to renew, but it was published in a form that was slow and painful to collect by hand. He asked, one day, if I could do anything with it.

I'd just finished an automation project built on an expensive enterprise tool that would have solved this easily. The catch was the cost: a tool like that runs from around $250 a month up to $20,000 a year, and for a job he'd run once a month, it would have sat idle most of the time. He didn't have that budget, and reaching for that tool would have been solving the problem with the wrong thing.

So I went back to my test-automation days and built a small script that runs in his own browser, free, that he runs himself once a month. Each run pulls anywhere from 100 to 3,000 leads, enough that he works through a batch and simply runs it again when he's ready. No subscription, no platform, nothing sitting idle, nothing to maintain.

I built it to be resilient to changes on the source site, and in five years of him running it, I've had to touch it once.

I did wonder whether to put it on a maintenance retainer or run it as a service. But the solution was simple enough that it genuinely didn't need me, and charging a recurring fee for something that runs itself isn't how I work. I'd rather he refer me to someone else than pay me rent on a script. That referral is worth more to me than any retainer, and it's the same reason I'd never sell a client more than they need.

A small manufacturer needed a web application as their primary sales channel: customers browsing the catalogue, configuring and ordering custom products, and tracking those orders, with the factory tracking them from the other side. It needed to work well, and it needed to be ready reasonably quickly.

I delivered it with AI-assisted development, and it came in with 35% less effort than a project like this would normally take. But the AI wasn't the reason it was fast. The reason was what we did before any code was written.

We spent the time upfront fully working out the logic and the workflow, and got the design detailed and specific before feeding it into Claude Design. Most people do this the other way around: they prompt the tool, generate something, and iterate toward what they want. We crafted the prompts out of design work we'd already thought through, so what came back was what we expected the first time. The build just flowed, because the thinking was already done.

The other half was the client agreeing to stay available, to answer questions and make decisions on call rather than parking them until the next meeting. That removed the usual cycle of assumptions, rework, and waiting. On a project like this I'd normally build in 20 to 30% contingency for exactly that churn. This time I took a chance that the client would commit to the approach, and dropped it. We finished early and under budget, and they moved straight on to phase two.

That's the whole idea in practice: do the understanding first, and the automation, AI included, becomes the fast and easy part. Rush to the tool first and you spend the saving, and more, fixing what you assumed.