In the last dispatch — four days ago — I made a bet out loud: that a decade of building software in public creates more leverage than a decade of excellent work no one can see. The first dividend showed up almost immediately.
I have a paying client.
Not from the blog — let me be honest about that. The client came through my network, not an inbound form. But the bet from the last post still cashed: the work I'd already put in public is what made the conversation easy. I could show what I'd built instead of describing it.
What I'm doing
This week I put up a page that says, plainly: you have a painful manual process, I build the tool that kills it. No agency, no deck, no six-week discovery phase — one operator who can sit with your actual workflow and ship the thing that replaces it.
It's the same loop as everything else I build, pointed at other people's problems instead of my own: find where a smart person is trapped in a spreadsheet, and build the thing that gets them out.
The first one
The first client is a 24/7 industrial equipment-rental company on the Gulf Coast — the kind of business that keeps refineries and construction sites running with lifts, compressors, generators, and pumps, around the clock, across multiple branches.
The problem was the one that's always the problem: the people closest to the money were running the business out of a spreadsheet and a stack of paper forms. Reservations, service calls, what's on rent, what's coming back — all of it lived in someone's head and a file that only opened on a desktop. The single most valuable number in the business — how much equipment is on rent right now — took real effort to answer.
So I built them a live rental board.
It's a passcode-gated, mobile-first web app in their own brand. Open it on a phone and the first thing you see is the number that matters: dollars and units on rent, returns due, open service calls. Their two real daily forms — the rental reservation and the service request — are now a few taps that save to a database and produce the exact text they already send. I loaded their real catalog so it speaks their language out of the box, not a generic demo.
The feature list isn't the point. The person running the branch now opens one screen and sees the business, instead of reconstructing it every morning.
How it actually got built
Fast. The working app took about four hours — not weeks, not months. That number sounds like magic and isn't: the hours are short because the hard part is done up front — understanding the workflow, loading their real catalog, getting the data model right. I work the same way I do on everything here: alongside Claude Code, with a real engineering setup around it. I write a tight spec, review and validate every output, and deploy and own the result. The AI does the mechanical lifting; the judgment is mine.
That's also why the economics work for a small business: they're not paying for a team of six and three months of process — they're paying for judgment and speed.
What this proves (and what it doesn't)
The way I build — outside a software company, alongside AI, shipping with a real address — produces something a business will pay for. That's the harder bar.
What it doesn't prove yet is repeatability. One client is an anecdote. The work now is to turn this into a before-and-after I can point to, and to do it again for the next business with a process worth killing.
If that's you — you've got a manual workflow that eats your week and you're done fighting it — that's the work I do.
One client doesn't prove the model. But it's the first thing I needed proven, and the bet is still running. If you want to follow along, subscribe below — the next dispatches go deeper on individual builds: what worked, what broke, and what's shipping next.