The second question is answered below, layer by layer. The first is why a team already carrying a full slate of business work built any of this at all, and the story that answers it is an old one.
The shoemaker’s children
The shoemaker’s children go barefoot, because every hour of the shoemaker’s day goes into shoes someone is paying for. Technology teams live the same way: everything we build goes to the business, and the small tools that would make our own work easier never find a sponsor. I have always tried to build them anyway, and for most of my career that meant building them badly or not at all, because a two-day internal tool cannot be justified against two days of work somebody is waiting for.
This is the part of AI-assisted development I find most underrated. It changed which work is worth doing at all: a diagnostic tool that would have taken three days, and therefore never got built, is now an afternoon. Several tools on this site exist only because of that shift, told where they live, on the skills library and the evaluation pages. And the pattern does not stop at small tools: the warehouse, the extraction platform, the shared templates are the team’s own shoes too. This page is what happened when they finally got made.
One of those deferred tools shows the division of labor in miniature: a wait-statistics dashboard for the database server, adapted from a community blog post the way I have adapted ideas for 25 years. The judgment inside the specification, which wait patterns matter and what deserves a recommendation, took years to earn and stays mine; the dashboard around it is an afternoon. Nobody calls reading a blog post a shortcut, and that inconsistency is a page of its own.
Where it started
Our data platform grew the way most do, one system at a time, each reasonable for its moment. As the organization scaled and our core clinical database moved to the cloud, the older designs started showing real strain: reports failed overnight for reasons that took until morning to trace, and a job that broke partway meant starting over. None of that reflected bad engineering; it reflected systems built for one set of conditions, later asked to run under another. Every project here grew out of responding to that shift, and the longer story of how I got here sits behind all of them.
The layers, and why they were built in this order
The map first, then the reasoning:
The data platform comes first because everything else stands on it. Without it, a request for a quick figure resolves through hundreds of undocumented views against schemas that change without warning, so a 20-minute ask costs days, every time. That is a foundation problem, not an estimation problem, which is why it gets fixed first instead of absorbed repeatedly. Medallion Hub is the warehouse, designed so its migration rewrites zero reports; Sluice is the extraction platform that feeds it reliably every night; and underneath both, the backup key rotation keeps the databases recoverable, the smallest work here and the least visible when it fails.
Shared infrastructure comes next, so applications stop solving the same problems twice. The job scheduler, hardened by a 27-day outage; the application template, whose documented pitfalls each trace to a real incident; the skills library, which holds the team’s working habits in version control; and the documentation platform, because a finding nobody can read might as well not have been found.
Applications come after the foundation and reuse it deliberately. The residential client portal replaced spreadsheets and 11 separate lists with one system of record; the ticket archive keeps a decade of retired history searchable without the old platform’s license; and the BI platform upgrade is planned in full and honestly not yet begun.
AI is built as its own governed layer, not bolted onto projects. The evaluation measured 16 local models and produced three documented conclusions that turned out to be wrong, all from trusting a single sample, which changed how I evaluate anything probabilistic. That capability grew into the private AI program, and the platform behind it was specified end to end before the build; One Machine tells how the pieces compose. The same discipline runs in reverse, pointed at the code AI writes: the methodology is its own page, and so is what building this way costs.
Why this matters as a whole
Read individually, these look like a warehouse, an extraction engine, some internal applications, and an AI experiment. Read together, they are one department moving from aging, individually maintained systems toward a single platform, with a measured, governed answer to where AI fits in the work. The order was not arbitrary: extraction before the warehouse it feeds, shared infrastructure before the applications that reuse it, and AI evaluated with the same rigor as any other infrastructure decision.
Read next: One Machine, how the AI platform was specified before it was built, or about me.