Seven great builds with one missing foundation. What Mulago’s AI infrastructure should look like (once it exists).
Every build below is great. Each one also had to answer for themselves where its data comes from, how to get structure out of it, where the result lives, and whether it is safe to point at grantee data. The orange tags are the answers that repeat. Click any tag to see how many builders solved that same problem, and click a card to turn it over.
Read bottom to top. Nothing here is a new system. It's the shape that already works at Mulago applied four more times: a declared source, a structured layer in between, and a surface people already visit.
One answer per data domain. The value is not in the choice, it's that everyone builds against the same answer/data source of truth. This is drawn as one working data layer on Airtable, which is my rec: one org record from first referral to last grant, so a fellow becoming a portfolio org is no longer going through an export and re-creation on the other side, and the sourcing history stays accessible by all. Salesforce becomes the archive, kept accurate and read-only since it contains so much history (but debatable if it's heavy cost to retain). It also settles the write question, because Airtable is formally the write layer and there is nothing to reconcile back - but we all have to then get comfortable with using AI inside our source of truth home.
Two caveats belong next to that. This is my recommendation, but the choice is ours to make together: the three candid options and the cheap experiment that decides between them are laid out on where things live. And Rahila's Salesforce audit runs through end of September; her position, which I agree with, is that you should not restructure a foundation you have not checked, so nothing should progress until her audit's through.
Drive keyed by org rather than by year and grant cycle, so knowing an org’s name is enough to reach its memos, financials and milestone docs. Box becomes the archive it is already becoming. This is a folder-architecture decision made once, within a migration already in flight.
The layer that replaces seven private builds. Each job runs the same way every time, with one step where the model is allowed to use judgment. Written once, pointed by four people at their own documents and their own field lists. This is Rahila’s Spotlight pattern turned into shared infrastructure. The reason it is drawn as one step rather than a whole pipeline of model calls is set out on the where things live page: almost everything the team has built used AI to get made and then runs without any AI inside it, and Spotlight is currently the only exception.
Claude projects do not go away. They stay the place people think, and a job graduates into the repo once it has proved worth repeating. Explore in a project, run from the repo. Two tools, two jobs.
Worth confirming with Alex whether a Mulago GitHub organisation already exists. Whatever he uses for the website is probably the right home rather than something new.
One hosting answer instead of three. Avery’s Cloudflare setup is the most developed pattern already in use, so it becomes the standard: the build is a static page, and Cloudflare Access sits in front of it as an identity check at the edge. No login code lives inside the build, which is why someone who is not an engineer can stand one up. Leaking the URL stops leaking the data, access ends automatically when a Mulago account is switched off, and every visit is logged.
What can point at grantee data (potential to create accessible and inaccessible to AI dBs in Airtable, similar to the plan for the Drive migration), which surfaces are sanctioned, and the expectation that anything making a judgment is measured against human agreement before it's trusted. Rules living in code makes them readable and checkable before a chron job runs. Every answer carrying a link back to its source makes a wrong one findable.
Not a data warehouse. Not a migration project. Not a platform that needs an owner. Mulago is fourteen people. The whole end state is five decisions, one folder structure, five pipelines and one hosting answer.