Walk through the real workflow
I spent years inside real businesses before I wrote production code. A messy workflow looks different to the person living in it. I go through it step by step and name what's actually broken.
Off-the-shelf tools rarely match a small service business, so the owner fills the gaps by hand: retyping, copying between systems, rebuilding the same documents. I walk through how the work really gets done, find the step that costs the most, and build the tool that removes it. One scoped build at a time, fixed price, and you own the code.
The client was retyping the same job three times. Intake on paper, quote in a spreadsheet, invoice in email. The build reads the handwriting, generates the contract, and puts the revenue on one screen. Nobody retypes anything.
I spent years inside real businesses before I wrote production code. A messy workflow looks different to the person living in it. I go through it step by step and name what's actually broken.
Scoped to the problem, built, tested, and deployed. Fixing one bottleneck shows you the next, so builds run in sequence. At C.R. Laurence, order entry came first, then configurator creation. You own what I build.
Claude Code does most of the typing. I decide what gets built and what gets left out, and I can tell when the AI gets something wrong.
A custom contract and operations platform built solo for a real client. AI that reads handwriting, e-signatures, and a live revenue dashboard, running in the business every week.
A personal-finance decision engine. Deterministic TypeScript, Next.js 16, running on Cloudflare. In development at tractionfi.com.
A product configurator automating 90% of custom manufacturing orders. C# business process methods on a live ERP.
I walk through how the work gets done, start to finish, including the parts that only live in one person's head. I find which steps repeat, which ones cause delays or mistakes, and which ones only work because someone remembers to do them. Then I write down what I'd build and what it costs. The build starts after that.
Most of the typing. None of the judgment. Claude Code closes the distance between knowing what to build and having it running. Deciding what to build and what to leave out is still the job.
They usually are, at least in part. That is the reason I go in first. When a requirement turns out to describe the workaround rather than the problem, I say so, show what I saw, and rescope in the same week.
Project-based service businesses, usually one owner or a small team. The owner is often the bottleneck, because too much of the work runs through them.
Fixed price, agreed before I start. I scope one bottleneck at a time, so the price covers a defined piece of work. You own what I build.