Johnny Ward has spent his career selling brand partnerships, the kind of deals that close because the buyer has known him for a decade. He works now as a fractional Chief Growth Officer under his own company, Forward, running new business for a small roster of clients.
I met him years ago when I worked for him, and I've handled his sales operations since 2022, 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 asked for more operations support. Target lists, call briefs, Salesforce hygiene, the usual fractional-ops menu. That scope survived about a day. We talked strategy for an hour 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 almost all of it until he approves. 80 days after that first commit, the repo held 854 commits. By October 14 it held 1,298, 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 asks for a contact in his format, 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 turned down a suggested contact in one line: a CMO 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.
Confirming where one person works now takes a few minutes of searching. There were about 8,150 contacts in his book.
The pain was volume. Several clients' pipelines run through his inbox, and every contact he touches needs research, notes, follow-ups, filing. A book built over decades 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 about 8,150 contacts 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."
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 described another way he wanted the Hub to work. The second was about the time he loses to filing and folders. The third asked for automated sequences with his sign-off in the loop.
Every request got run through 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. About 19 workflows run on that spine now. When he emailed one afternoon asking the Hub to pull his client's past press coverage into outreach emails, the capability had a track into production that same week. On October 8 he called at 10:30 to change how every client's pipeline groups prospects before his 11:00 client call, and it was live at 10:37. 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. By October 14: 1,298 commits, 123 migrations, about 152,800 lines, 167 API routes, and 51 checks that must pass before any deploy goes out. 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 asked for sequences he could approve before anything went out, and that became the architecture. Every workflow in the Hub produces proposed actions, and almost all of them run only after he approves. When he runs an ask, the Hub shows him the plan first. The button says "Approve & run." A few narrow, rule-gated writes run on their own (moving a contact who changed jobs, filing a note or a call the system is confident about), and every one is logged and reversible.
2 design rules live underneath that gate.
A contact update that can't be corroborated by a second data source doesn't get written.
First: the Hub doesn't send email itself. 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. A sequence enrollment goes out through Apollo only after he approves it. 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. The Hub does the research and writes the draft. Johnny is still the one who sends it.
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 June: keep Salesforce current on 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 decades-old 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 contact list went from about 8,150 to about 4,000 real ones. 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 he couldn't have staffed by hand: 95 existing contacts verified and enrolled into sequences, and 39 new director-level contacts researched into Salesforce.
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 with its reason, 456 of them by October; a reversed decision gets replaced in 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 it's rebuilt from commit timestamps instead of estimated, which is where the hours in this article come from.
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. I 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 first 80 days took about 353 logged hours across 36 working days, about 3 build days a week. By October the log was at about 493 hours over 71 build days.
Johnny never wrote a ticket or learned a project tool. He emailed, called and texted the way he already does, 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.
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 5 months old, and it still gets rebuilt every week Johnny finds a new edge of it.
