Johnny Ward has been selling for 30 years. Brand partnerships and celebrity gifting, the kind of deals that close because the buyer has known him for a decade. He works now as a fractional Chief Growth Officer at Forward Marketing, running business development for 3 companies at once, on the 60 hours a week he's willing to give it.
I met him years ago at a creative agency he ran, and I worked with him long enough to learn how he actually operates. That history is doing more work in this story than any technology decision in it. The good calls in the software all came from knowing things a discovery call never surfaces: how he formats a contact note, and which titles he'll pick up the phone for.
In May 2026 he brought me in for operations support. Target lists, call briefs, Salesforce hygiene, the usual fractional-ops menu. That scope survived about a day. We talked strategy for 45 minutes on May 11, and that evening I wrote a 962-line spec for something called the Forward Ops Hub. The first commit landed at 7:23 the same night.
The Hub is an ops system with exactly one user. Johnny types requests in plain language: prep me for my 2pm, make a contact for the person who just emailed me. The system runs the work against his real Salesforce, Apollo, and Microsoft 365 accounts, drafts everything in his voice, and holds the results until he approves them. 80 days after that first commit, the repo held 854 commits, and the Hub is what his mornings run on.
01The client I already knew
Johnny's operating system predates software. He sells by phone and email, tens of conversations moving on any given day. Salesforce is his notebook, the place where everything true about a relationship gets written down. His contact notes have a house format he's refined for years: who the person is, what the company does, how he knows them, whether they've met. When he forwards a thread and says "make a contact for them, and structure the note the way I like it," the note has a right answer. He knows when it's wrong.
I didn't have to discover any of that. I'd watched it for years. I knew he lives in Outlook, sends before 9, files everything, and holds exact instincts about who's worth his time. Early in the build he rejected a suggested contact with 3 words: "CMO is too big." He meant the title was too senior to buy what his client sells. You only learn rules like that from years of working next to someone, and his head holds hundreds of them.
It takes a few minutes of searching to confirm where one contact works now. Johnny's book had 8,173 of them.
The pain was volume. 3 companies' pipelines run through his inbox, and every contact he touches needs research, notes, follow-ups, filing. A book built over 30 years also decays on its own: people change jobs and companies get acquired. Confirming where one person works now takes a few minutes of searching. There were 8,173 records in his book.
The first spec was honest about the bar. The design target written into it: Johnny glances at the Hub for 10 seconds and knows whether he's on track. The aesthetic target, quoted from the spec: "If it feels boring and serious, it's right." A 30-year sales executive doesn't want another app to learn. He wants his hours back.
023 emails in 19 minutes
The first version was a dashboard. 13 database tables, 4 pages, today's calls, today's meetings, a daily checklist, built in one night because the spec was finished before the code started. Johnny used it. Then he started asking for things.
On the morning of May 19 he sent 3 emails: 9:47, 9:55, 10:06. The first opened with "Another way I'd like the Forward HUB to work." The second described the time he loses to filing ("I spend a lot of time creating folders and saving things"). The third asked for automated sequences with his sign-off in the loop.
Every request got one question first: is Johnny describing one thing, or a class of things?
That morning forced the most important decision in the build. I could have built the 3 features. Instead, every request got run through one question first: is Johnny describing one thing, or a class of things? All 3 were classes. So the Hub got rebuilt around that fact. One entry point, called Ask Forward, where he types whatever he wants, and a router model that reads each request and picks the workflow to run. Workflows became the unit of construction: adding a capability now means registering a handler, one code module on a shared spine, about a day of work.
That decision is why the Hub kept up with him. 16 workflows run on that spine today. When he emailed at 12:46pm one afternoon asking the Hub to pull his client's past press coverage into outreach emails ("very important item"), the capability had a track into production that same week. When a live call surfaced 3 corrections to a research page, all 3 were checked against the data before a line changed, then shipped. This feedback loop is the reason I build custom instead of configuring someone else's product. Johnny's smaller asks were usually live the same day; the big ones became workflows within the week.
80 days of that loop, by the numbers: 854 commits across 36 working days, 77 database migrations, about 112,000 lines of TypeScript, 139 API routes. I ran it the same way I ran the CODA build: a strategy layer, an implementation layer in Claude Code, and me arbitrating in the middle.
03Nothing sends without him
The 10:06 email from that Tuesday morning had one sentence in it that I've thought about since: "I actually really like receiving emails that a sequence has been set but needs my final approval."
That sentence is the architecture. Every workflow in the Hub produces proposed actions, and proposals execute only after approval. The code enforces this at the type level, which means a workflow that drafts an email has no path to his Salesforce or his calendar at all; only the approval step does. When he runs an ask, the Hub shows him the plan first. The button says "Approve & run."
I actually really like receiving emails that a sequence has been set but needs my final approval.
2 design rules live underneath that gate.
First: the Hub never sends email. It drafts in his voice, grounded in his own notes and his past correspondence; the drafts land in a queue, and Johnny sends from his own tools. The queue pays attention to what happens after. Every draft is stored in 3 versions, what the Hub generated, what Johnny edited it into, and what he finally sent, and the drafting workflows learn from those diffs, so the next draft starts closer to how he would have written it. I measured why he stays the sender. An analysis of years of his sent mail, 62,322 messages, showed that when Johnny writes to a new contact himself, replies come in at 2.51x the rate of template-shaped email. His sending is the asset. The system's job is to protect it, so the machine does the research and the assembly, and the thing that reaches a prospect is still him.
Second: when the system isn't sure, it produces nothing. A draft that needs a supporting press link either carries a verified one or flags the gap for a human instead of inventing one. A contact update that can't be corroborated by a second data source doesn't get written. The same posture runs through every switch in the build: sending and sequence enrollment both shipped disabled by default, and any run that spends money requires a typed confirmation first.
04The CRM caught up to reality
Years of layoffs and job-hopping had scattered Johnny's book. Contacts listed at companies they left 2 years ago, titles from 3 promotions back. He asked for this fix in his own words in June: keep Salesforce "constantly updated to reflect exactly" where each contact works today, because confirming people one at a time was eating his selling hours.
So the Hub worked his entire active book, all 3,882 contacts. It confirmed the ones still in place, found 131 people who had moved, and re-pointed their records: new company, new title, and a verified new email for 107 of them. Another 132 titles got corrected along the way. The checking runs as a cascade across providers, Apollo for employment history, Seamless to confirm the new title, Hunter to find and verify a fresh email, each doing the one step it's best at, with the rules tuned to Johnny's own definitions of a fit. Every write was logged with before-and-after values and is reversible by run, because an autonomous system editing a 30-year book should leave a paper trail.
The cleanup cut the noise in half. With Johnny's sign-off, 3,887 empty record shells came out (no notes, no activity, no persona), and his account list went from 8,123 to 2,464 companies that exist in his world. Persona coverage across the book is 98.7% now, which is what makes a question like "who should I reach out to today" answerable.
That question got its own page in the Hub, because it turned out to be his #1 ask. In June he described his ideal morning: show up at 9am to a ranked list of 5 or more contacts worth his time that day, so his energy goes to calls and pitch meetings instead of research rabbit holes. The Hub now scores his whole book nightly, 1 to 100, using signals from his own email threads alongside market signals, and the bands use his vocabulary: Reach out now. Warming. Watch.
The target board keeps score without being told. When Johnny sends an email from his own tools, a reconcile job spots the send, updates that contact's card, and closes the loop on the board, usually inside 15 minutes. His outreach list stays current because it updates itself from what he sends.
When a real deadline hit, the same machinery carried an outreach push at a scale he couldn't have staffed. An award-season sprint verified and enrolled 95 existing contacts into sequences and researched 39 net-new director-level contacts into Salesforce. A Latin-market list ran 8 research agents across 164 target brands and came back with 64 marketing leads, 48 of them with verified work emails.
05The repo keeps its own books
A solo operator building with AI agents has a continuity problem: the project's memory lives in chat sessions that end. The Hub's answer is a state spine inside the repo. Every decision is a typed file, 276 of them so far, and only 5 have ever been reversed; a reversed decision gets removed from the active set by its successor, so the record can't contradict itself. Every open request is a database row that knows which capability it blocks. The docs regenerate from the code, and a drift check runs before every deploy: if the documentation and the code disagree, the build fails and nothing ships.
That discipline is also how I keep the numbers in this case study honest. The time log is part of the spine, and early on I audited it. Claude estimates each session's length as it logs, and I noticed a day where the log claimed about 27 hours of work against roughly 9 elapsed hours in git. The estimates were running 1.5 to 2x real time, consistently. So I rebuilt the accounting from commit timestamps, corrected the first 50 sessions down 35%, and the log has run on the corrected method since. The 353 hours in this article come from that corrected log, which is why I'm comfortable publishing them.
All of this on a single-user build, because I'm a solo shop: if I lose the thread of what was decided, or Johnny loses confidence in what the system wrote, there's nobody else holding either. Johnny can open a status page any day and see what's live, what's blocked and on whom, and what was decided about anything, with dates.
06What this costs and where it fits
The whole engagement, metered: 854 commits over 80 calendar days, roughly 353 logged hours across 36 working days, about 3 build days a week. The Claude API bill for all of it was $145.67, measured by the Hub's own usage telemetry across 18,883 model calls; infrastructure runs about $50 a month. I keep re-checking the spend number because it reads like a typo.
The number I'm proudest of is 1.5. That's the total hours of client communication logged across the whole build: one 45-minute strategy call, then email. Johnny never sat through a status meeting, never wrote a ticket, never learned a project tool. He emailed the way he already emails, and the system grew around the requests.
This model fits a specific shape of client: a principal with a real book and a working sales motion, where the software's only job is to multiply habits that already close deals. Systems of record already in place; his Salesforce and Apollo both predate me. And an operator relationship with history in it, because the fit comes from knowledge that no kickoff meeting produces. Where it doesn't fit: a team that needs seats, permissions, and onboarding, or a business still searching for its motion. Stretch a build like this across a team and you're writing SaaS, badly.
If you run a book like Johnny's and the grunt work is eating your selling hours, this pattern is buildable for you. The first conversation is 30 minutes, and if your setup doesn't fit, I'll say so on the call. demo.outblox.com shows what a live build looks like from the front.
The Hub is 80 days old, and it still gets rebuilt every week Johnny finds a new edge of it.