Three ways in. Most people start with the first, and a fair number stop there — finding out that something isn't worth automating is a useful answer too.
You fill out the intake form, we talk, and I look at how the work actually runs day to day.
Sometimes there's a clear problem to solve, and the report covers where your hours go, what could be automated, what it would take, and what it's worth against what it costs. Sometimes there's no problem at all — you're just curious about your own numbers and nobody's ever had time to look. That's a completely normal reason to hire me, and the report is the analysis itself: what's in your sales, your customers, your labour, and what stands out.
Either way you get a written report, and it's yours no matter what happens next. If you take it to someone else to build, that's fine by me.
If there's something worth building, I build it, in pieces you can actually use as they land. A plan almost never survives the first working version, and I'd rather find that out in week one than week eight.
Everything comes with a handoff document — how it's put together, why things were done the way they were, what the known limitations are, and what a next step would look like. Written for whoever ends up looking after it, which might not be me.
Two versions of this. If a system is doing something important, someone should keep an eye on it — services change, the tools you connect to change, and the volume you built for in spring isn't the volume you've got by winter. Not every build needs it; if something's genuinely set-and-forget, I'll tell you and hand you the keys.
The other version has nothing to do with software. Some people just want their numbers looked at regularly — quarterly, seasonally, before a big buying decision. No system to maintain, just a recurring analysis and a conversation about what's in it.
I use AI a lot, but pretty specifically. It's great at technical and repetitive work — reading through thousands of files, pulling structure out of messy data, connecting systems, doing the boring parts of a job. That's most of what I build.
I'm a lot less interested in it as a replacement for creative work. The stuff people actually value about your business — the judgement, the voice, the taste — doesn't come out of a model. So the AI does the boring part, and a person keeps the decisions.
I don't publish rates, because I don't know what you need yet, and a number without a scope attached isn't much use to either of us.
The diagnostic is a fixed fee, and you'll know that number before we start, so there are no surprises. Everything after that we price once there's something specific to price — builds get quoted against a defined scope, and ongoing work is monthly. Where a system uses paid AI services, those costs are passed through at cost plus 10%, and you always see the underlying number.
General IT support, website design, and social media aren't things I do — there are people much better at those than me.
And if the underlying process is broken, automating it usually just makes it break faster. If that's what I find, I'll tell you, and fixing the process first is often the better use of your money.
I use models where real judgement is needed, wrapped in code that checks what comes back. Anything that can be handled by ordinary code is handled by ordinary code.
Things should keep running when nobody's watching. If one piece isn't set up, it should skip quietly instead of taking the whole thing down.
You get pieces you can use and react to. A whole build dropped on you at the end is how projects end up technically done and practically useless.
Documentation written for the person who inherits it, whether that's you, a developer you hire later, or someone on your team.