GatesHub, also known as GatesBrain, is the connected-data portal I built for the Gates Institute at CU Anschutz. It's live at gateshub.company, behind a login; the demo above is the tour. Around a dozen modules run on it today. LIMS (laboratory information management system), ERP, and the quality management system (qPulse) feed a single hub, and the institute's daily workflows run on top of it. It was built kaizen-style, a bite at a time, and adopted the same way: pilot by pilot, stakeholder by stakeholder.
This case study is half software, half coalition-building. The second half is the harder one.
The problem
The Gates Institute is academia and pharma combined, and over the past decade it grew from the Gates Center into the Gates Institute at startup speed. Growth like that invites the standard failure mode of any organization at that stage: systems talk to each other pairwise, or not at all. The lab system doesn't know what the ERP knows, quality management sits on its own island, and a question like "what is this person working on, and what does it cost" has no single place to be answered.
Systems talking pairwise multiply: ten of them is forty-five integrations to maintain. Ten talking to a hub is ten.
The architecture: hub-and-spoke
I'm a proponent of the hub-and-spoke model at Gates, not its inventor, its advocate. The argument I made internally is simple:
- Each system integrates once. LIMS, ERP, and the quality management system (qPulse: equipment preventive maintenance, SOP documents, everything at the facility that should be standardized) each feed the hub. No system needs to know about any other system.
- Every question has one address. When the data lives in one place, a dashboard, a report, or a quote pulls from the same source of truth.
- Agents become possible. This is the real payoff. An AI agent can only act on an organization it can see. Scatter the data across silos and every agentic project starts with the same expensive plumbing. Put it in a hub and one integration serves every agent you build afterward.
Hub-and-spoke is old advice. Agentic building is what makes it urgent.
What runs on the hub
Around a dozen modules are live. The ones doing the most work:
User interviews. The highlight. It gets its own section below.
Finance dashboard. The institute's numbers, on the same hub as the work that generates them.
Employee dashboards and quoting. Each person's current work and billable hours, on one screen, and the dashboards feed the quoting system for incoming clients. That's the mechanism worth noticing: a quote for new client work is only as good as your picture of current workload and billable hours. The hub holds both, so quoting stops being guesswork.
Onboarding and training. I-9s, document upload, equipment requests: everything onboarding and upskilling, in one place. Unglamorous, high-frequency workflows, which is exactly why they belong on the hub. Every one is a small daily proof that the system works.
Org-health screenings and feedback. The hub reads the organization, not just its transactions.
Market intelligence and market pitches. The outward-facing research beside the operational data it should inform.
CRM. Connected to the same hub, so client relationships sit beside the operational data instead of in another silo.
Plus the rest of the dozen: LIMS itself surfaced in the hub, the org chart, forums, FACT (the accreditation evidence-mapper, its own case study), and the admin page that runs it all.
The highlight: user interviews in a day
The institute's tech analysis needed user interviews. The usual way to get them: weeks of scheduling one-on-ones, then more weeks writing up notes. I built a module instead.
People talk their answers. Whisper transcribes as they speak. While they talk, AI digs into the responses live, pulling more detail out of every pain point it hears. No calendar Tetris, no note-taking backlog, no waiting for a synthesis meeting.
User interviews and feedback that would have taken weeks landed in a day.
How it was built: a bite at a time
GatesHub grew kaizen-style: ship one small piece, let people use it, ship the next. Each bite was small enough to build quickly and useful enough to defend itself.
The compounding is the point. Any single piece (an equipment-request form, a billable-hours view) looks minor. Stack them for long enough and it grows into something large, because each piece earned its keep before the next one was built.
Where it sits now
The hub lives at gateshub.company, auth-walled, so a visit gets you a login screen; the demo above is the tour. Two other Gates Institute tools I built ship on its subdomains: FACT-Codex, the accreditation evidence-mapper, at fact.gateshub.company, and the CGT Intelligence Dashboard at market.gateshub.company. Each has its own case study.
The buy-in strategy: pilots inside pilots
Software is easy to build and hard to adopt. At a university, adoption means winning over stakeholders who don't report to you and don't have to care.
My approach: pilots inside of pilots. Each stakeholder group gets a small pilot scoped to a pain they already feel. CU Innovations (tech transfer), donor outreach, grant management, CMC production, fiscal compliance: federal, private, and internal. A win with one group becomes the introduction to the next.
Here's the ladder as it stands. Small wins are landing now inside the finance team, leadership, and the front-door strategy team. From there: Gates as a whole. Then Gates as the pilot for the university. Then the smaller schools and programs at CU. Then UCHealth and CU Medicine. Each rung is earned by the one below it. Nobody is asked to bet on a platform. Each group is asked to try one small thing. The platform is what the small things add up to.
This is the same thesis that runs through everything I do: translational medicine is a team sport. The science only moves when tech transfer, donors, grants, production, and compliance are bought in, and the same is true of the systems that carry the science. The build alone isn't the product. The coalition is.