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. It cashed almost immediately.
A company I know needed a real tool — and I built it.
The relationship came through my network, not an inbound form. But the bet from the last post still held up: 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.
The problem
The business is a 24/7 industrial equipment-rental company on the Gulf Coast — the kind 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 work 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.
What I built
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 got built
The visible app is the easy part to talk about — and it's not where the work is. The hard part is up front and unglamorous: sitting with how the business actually runs, loading their real catalog, and getting the data model right so the tool reflects reality instead of a generic template. 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.
What this proves (and what it doesn't)
The way I build — alongside AI, shipping with a real address — turns a messy real-world process into working software a business can actually run on. That's the harder bar.
What it doesn't prove yet is repeatability. One build 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 process worth killing.
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.