Account Hub: Shipping the Platform an Org Runs On, in Five Months
In December 2025 I spent my days sitting next to Account Managers, watching them work.
Not interviewing them — watching. There's a difference. When you ask people what they need, they describe a better version of what they already have. When you watch them, you see the fifteen browser tabs, the campaign IDs pasted between systems, the servicing request that lives in a Slack thread until someone remembers it. Nobody files a ticket about the water they swim in.
Seven months later, the platform that came out of that shadowing — Account Hub — was the most-viewed internal application at the company, released nationally to the entire US Account Management org. A two-person team built it. I wrote 59% of the commits.
This is the case study of those five months of building, and the working method that made a two-person team enough.
From Shadowing to a Hackathon Prototype
The observations from December became the brief for a company hackathon in February, where I prepped as technical lead. Two days later we had a working prototype — campaign pacing, delivery-risk flags, account rollups in one place — and first place.
Hackathon wins are usually where internal tools go to die. The demo works, the applause happens, the prototype rots. The difference this time was that the prototype had been scoped from field notes, not imagination: every panel in it mapped to something I had watched someone struggle to assemble by hand.
The Constraint That Became the Product
Early on we hit a mandate that reshaped everything: the servicing workflow could not introduce a new ticketing system. Account Managers already lived in Jira, Slack, and email; adding a parallel queue would have guaranteed abandonment.
So instead of building a ticketing feature, I built a full two-way Jira integration — create, read, update, attachments, templated request types with the right fields for each workflow, assignee routing backed by a directory cache. The "boring integration work" was the product. Users got one surface that spoke fluently to the system their teams already ran on, and adoption never had to fight muscle memory.
That pattern held everywhere: meet the users inside the tools they already trust, and make the new surface the place where those tools finally agree with each other.
How a Two-Person Team Ships a Platform
The stack was React and TypeScript on Retool, over Databricks SQL with Postgres caches. The method mattered more than the stack:
Weekly releases, every week, visibly. A platform earns trust by changing in response to what users said seven days ago, not seven weeks ago. We shipped on a weekly cadence from beta onward, and every release went out with release notes users could recognize themselves in.
Everything users say becomes a ticket, verbatim. After one user session I filed six issues in their own words. Paraphrasing user feedback is where the truth leaks out of a backlog.
Tests are the second developer. With two people, there is no QA team. 275 test cases across the component library were what let us release weekly without burning weekends on regressions.
The default view is the only view that matters. Configurability is a tax most users never pay. The pacing flags, the risk tones, the rollups — the defaults had to be right, because the defaults are the product.
AI recommends; humans act. The email-context assistant drafts and suggests, but it never auto-creates and never silently checks a box. In a tool that touches live client work, the cost of being wrong is real, so every AI-generated output is something a human accepts, edits, or dismisses.
Surviving the Executive Review
In May the platform went through an executive review that decides which internal tools live. We walked in with usage data from an 18-tester beta, a visible weekly changelog, and users who had already made it part of their morning. It lived.
July 9 was the US national release. Within weeks, Account Hub was the most-viewed internal app at the company — about 1,600 views a month, with dozens of servicing requests flowing through it weekly, and a zero-failure record on the request pipeline.
What This Actually Demonstrates
The FDE-shaped lesson, if you want it compressed: the hard part of internal platforms is not the code, it is the distance between the builder and the user. Every practice above — shadowing before speccing, verbatim tickets, weekly visible releases, defaults over configuration, recommend-don't-act AI — is a way of collapsing that distance.
A two-person team was enough because nothing we built had to be guessed.