From pilot to programme — an MVP's playbook for scaling a social-good AI project on Azure

The six-month wall#

Most social-good AI pilots I watch around Durban and South Africa more broadly die at roughly the same point — somewhere between the fourth and seventh month, at the moment the original free credits run out, the founding volunteer runs out of unpaid hours, and the first real user support ticket arrives that cannot be answered by looking at the demo script. You can usually predict which pilots are about to hit the wall from three months out, because the signs are operational, not technical. The model works. The infrastructure does not.

This article is a playbook for getting past the six-month wall on Azure. It is drawn from two pilots I have been running in parallel for the last year — ConservAxion, an impact-verification platform in KwaZulu-Natal, and Pfula, a bilingual South African government-services assistant — both built on Azure AI Foundry and the surrounding Azure stack. Neither has “graduated” in the full institutional sense; both have made it past the wall, which is the harder and less-celebrated thing.

The playbook is deliberately unromantic. The ideas in it are the boring ones, for the same reason that the pilots they keep alive are the ones that deserve to live.

Credits are not a strategy#

Every Microsoft for Startups grant, MVP benefit allowance, and social-impact Azure credits programme I have looked at has the same shape: a large-looking dollar figure, a fixed or renewable term, and a surprisingly tight definition of what it covers. The failure mode is not running out of credits; it is running out of credits at exactly the moment the project becomes real enough that you cannot turn it off.

There are three habits that keep this from killing you.

First, treat credits as runway, not as budget. Run a monthly az consumption usage list and project the burn rate forward. Assume your burn rate will triple in the quarter after your first partnership letter lands. Plan for the credits to run out three months before they will actually run out.

Second, identify which resources are operationally mandatory and which are scaffolding. In ConservAxion, the operationally mandatory set is short: Azure Functions, IoT Hub, Cosmos DB, Confidential Ledger, Foundry / Azure OpenAI, Static Web Apps, Key Vault, Communication Services. The scaffolding — App Insights at the default ingestion rate, a second subscription for a staging slot, the region-redundant backup that nobody has ever restored — is always where the cost overruns hide. Know the difference before the credit statement arrives, not after.

Third, move to paid tiers on your own schedule, not on the funder’s. If the pilot is going to graduate, the paying-customer-shaped entity is going to ask who pays the infrastructure bill. You want to have an answer that is not “we were on a grant and the grant has now expired.” That answer is much easier to construct in month four than in month seven. A Basic tier that the operator pays from revenue is a vastly more durable posture than a free tier funded by somebody’s goodwill.

Managed identity as operational hygiene#

If there is one technical practice that separates the pilots that make it from the ones that do not, it is managed identity. Not “we plan to adopt it.” Actually adopted. Deployed. Auditable.

Both ConservAxion and Pfula are managed-identity-first across every service. Cosmos DB access is through MI + RBAC. Key Vault secrets are accessed via MI (via RBAC, not access policies). Foundry / Azure OpenAI is called with a bearer token minted from a DefaultAzureCredential that resolves to the container app’s system-assigned identity. The single long-lived secret in Pfula’s architecture is the optional AZURE_OPENAI_API_KEY available for local development, and the .env.example carries a warning that it should not be set in production.

There are two reasons managed identity earns its place this aggressively. The tactical one is that it removes the drip-feed of “I rotated the connection string for X and forgot to update Y” incidents that eat your week every month of your life. The strategic one is that it shortens compliance conversations with institutional partners by about three orders of magnitude.

Every South African funder of any size now has a security questionnaire. Every one of them asks some version of “how do your services authenticate to each other?” If the answer is “managed identity — we carry no long-lived credentials between services in production,” the next question is about something else. If the answer is “we use shared access signatures stored in a key vault,” the next eighteen questions are all about that.

This is the single most load-bearing operational decision in either pilot. It is also, I think, the most under-emphasised in the material aimed at first-time Azure social-good builders. Most of them start with a quickstart that az login and injects a connection string into environment variables, and they carry that shape into production because nothing explicitly tells them not to. They should be told, explicitly, not to.

Infrastructure as code as documentation for future-you#

The third habit that survives contact with reality is infrastructure-as-code, but not for the reasons most tutorials give for it.

The usual sales pitch for Bicep or Terraform is repeatability — you can re-provision your environment in a new region, spin up a staging mirror, respond to a disaster by re-running the template. All of that is true and worth having. But the actual reason infrastructure-as-code matters on a social-good pilot is much more banal: it is how you remember what you did.

Six months into a pilot, the exact sequence of az commands that produced the working environment has fallen out of anyone’s memory. The original developer has moved on to other work. The portal view of the resource group shows seventeen resources and does not explain why any of them exist. If the pilot is on the cusp of a hand-over — to a permanent team, to a partner organisation, to the person who is replacing the original developer — a Bicep template in a repo is the only artefact that reliably conveys the shape of the deployment. Written documentation decays. Diagrams go out of date. IaC templates are, at worst, stale in a way that diff-reviews against the live environment will make loud.

Both ConservAxion and Pfula ship with deployment automation — Azure Pipelines YAMLs, az provisioning scripts, a Bicep-style shape even where the current surface is bash. That is not resume-ware. It is insurance against the day that the pilot needs a new developer.

Foundry as the default stack for Microsoft-aligned funders#

There is an observation about funder alignment that is worth saying out loud, because the people in a position to write it down usually don’t.

If you are pitching a social-good AI pilot to a Microsoft-aligned funder — AfOx, Microsoft Philanthropies, a development-finance institution with a Microsoft-heavy IT estate, a state entity doing e-government — building on Microsoft Foundry makes the pitch shorter by about forty minutes. Not because Foundry is categorically better than any specific alternative for any specific workload; for specific workloads, it often isn’t. Because the conversation does not have to start with “why are you running this on a stack my compliance team has never seen.” The compliance team has seen it. The identity surface is the identity surface they already run. The data residency story is the one they have already argued internally.

This is a soft factor and I am suspicious of it too. But when a pilot survives the wall and starts looking at funded graduation, soft factors become hard factors. Pfula’s escalation-letter pipeline runs on Foundry Agent Service. ConservAxion’s photo and telemetry validation runs on Foundry via Azure OpenAI. In both cases the choice was partly technical and partly about shortening the funder conversation, and in both cases I would make the same call again.

What the MVP programme uniquely rewards here is the ability to articulate why Foundry is the right choice for a specific problem — the Azure Confidential Ledger integration for impact-verification, the Agent Service tool-per-service shape for grounded government-services assistants — rather than the generic “we chose Azure.” An MVP who can talk about Foundry at the level of specific architectural affordances is directly useful to a funder audience trying to decide whether to bet on your pilot.

The human bits nobody writes about#

Two things that are not technical at all and matter more than most of the above.

The first is letters of support. Every serious funder wants a named operational partner who has put their name in writing behind the project. Get one early. Get them to sign a letter that explicitly speaks to the Azure surface, not just to the intent — the Foundry-based verification, the managed identity posture, the specific architectural choices that distinguish the pilot from a generic AI project. A good letter shortens diligence. A generic letter lengthens it.

The second is governance. If you are doing anything adjacent to citizen data or ecological data, somebody is going to ask about your data-governance policy eventually. The minimum viable policy is one document, two pages, that specifies: (a) which data is collected, (b) where it is stored and for how long, (c) who can access it and under what conditions, (d) how subjects can request deletion, (e) who the responsible human is. On both ConservAxion and Pfula that document exists and precedes the first external data collection. It does not have to be sophisticated. It does have to exist.

What the playbook reduces to#

Four rules, in descending order of “how often I have seen this kill a pilot that could have survived it”:

One. Treat credits as runway, plan for their expiry three months early, know which resources are operationally mandatory and which are scaffolding.

Two. Managed identity across every service, no long-lived credentials between Azure resources in production. The compliance dividend alone justifies the migration cost.

Three. Infrastructure as code as a memory aid for future-you, not as a dev-ops badge of honour. The template is the deployment.

Four. Make architectural decisions legible. On Microsoft-aligned funder tracks, “we use Foundry because X, Y, Z specific capability” travels much better than “we are on Azure.” Pick the specific Foundry capabilities that distinguish your pilot, and be ready to defend the choice on technical grounds.

None of this is glamorous. The MVPs I respect most — the ones whose pilots are still alive five years later — are the ones who quietly learned these rules, mostly the hard way, and started applying them before they had to. The MVP programme rewards that pattern when it sees it. So does every social-good funder I have ever worked with. The goal is not to have the most exciting architecture in the room. The goal is to still be in the room next year.