Sentinel Health: Winning the Google Build with AI Buildathon Southern Africa 2026

On Thursday, 30 April 2026, from 5pm to 7pm SAST, I joined the Google Build with AI Buildathon Southern Africa. It was a virtual event hosted by GDG and the Developer Ecosystem SSA Team, and the constraint was deliberately sharp: take a posed problem, design a solution, build quickly, and show something working.

My project, Sentinel Health, placed first.

That result was encouraging, but the more useful part was the process. The buildathon became a compact test of spec-driven development: move from an idea to a clear spec, turn that spec into a small PRD, and then build from the PRD with a backend, a frontend, and a deployable path.

The biggest learning was not simply that AI-assisted programming is fast. It was that AI-assisted programming becomes much more powerful when the fundamentals are already in place: a clear user, a constrained workflow, a backend/frontend boundary, a safety model, and a cloud deployment target.

The presentation room for Google Buildathon Southern Africa 2026.

The brief and the spec

The problem space was community health in rural settings. The user I designed around was a community health volunteer who needs to capture patient information, recognise urgent cases, and help a district team see what is happening across incoming cases.

I framed the prototype around one question:

Can we make intake faster for a community health worker while keeping safety-critical decisions deterministic and reviewable?

That framing mattered. Without it, the project could easily have drifted into an unsafe “AI diagnosis” demo. Sentinel Health was not that. The spec was narrower: intake, triage support, referral signalling, and district visibility.

Spec to PRD to build

The first useful move was not code. It was turning the brief into a small PRD.

In a 60-minute build, writing a PRD can feel expensive. In practice, it saves the build because it turns vague intent into executable decisions. I used it to make the following constraints explicit:

• The user is a community health volunteer, not a doctor.
• Voice input can help populate a form, but a human must review the structured fields.
• Danger signs should be detected through deterministic rules, not model judgement.
• The AI path is decision support, not diagnosis.
• The demo needs a complete loop: intake, review, referral signal, and district dashboard.
• The implementation needs both a backend and a frontend, not just a prompt demo.

That PRD became the build plan. The backend would own intake, rules, model calls, persistence, and API contracts. The frontend would own voice/form capture, review, and the district dashboard. Once that split was clear, AI-assisted programming could help generate and iterate on code without constantly renegotiating the product shape.

What Sentinel Health did

By the end of the hour, the prototype showed a complete workflow across both sides of the system:

• A React frontend for voice-assisted and form-based intake.
• A FastAPI backend handling case submission and model calls.
• Gemini-assisted extraction to convert messy intake text into structured fields for review.
• Deterministic danger-sign rules for urgent referral paths.
• Gemini-assisted triage support for non-critical cases.
• An offline-style queue to mimic unreliable connectivity.
• A district dashboard showing case flow, urgent referrals, and outbreak-threshold alerts.
• BigQuery-backed event storage so intake events could feed analytics.

The cloud surface was intentionally pragmatic: Cloud Run for the frontend and backend, BigQuery for events, Secret Manager for backend-only secrets, Cloud Build and Artifact Registry for deployment, and Cloud Logging for basic visibility.

Containerised for a real deployable demo

One practical detail mattered more than it might sound: both the backend and the frontend needed to run in Docker containers. The goal was not just to show code locally. The goal was to put a deployed POC in front of the judges so they could open the application, click through the workflow, and interact with the solution themselves.

That meant splitting the system into two independently deployable Cloud Run services:

• A backend container running FastAPI.
• A frontend container serving the React application.

That separation kept the demo honest. The frontend could focus on intake, review, and dashboard interaction, while the backend owned the API contract, triage workflow, model calls, rules, and persistence. It also meant each side could be built, deployed, and reasoned about as its own service instead of treating the whole prototype as a single local demo.

On the backend, I used FastAPI with Pydantic schemas for both ingress and egress. That gave the application a concrete data model: requests coming into the API had to match an explicit schema, and responses leaving the API had to be shaped predictably for the frontend. In a project with AI-generated or AI-assisted code, that kind of boundary is important. It gives the model a clear contract to build against, and it gives the human developer something explicit to inspect.

BigQuery was a pragmatic buildathon choice because it was available, familiar, and effectively free for the scale of the prototype. It was good enough for event-style storage and downstream analytics in a demo. For a real production application, I would not treat BigQuery as the primary transactional backend. Patient intake, case state, review status, referral state, and operational updates are OLTP concerns. A production version would need PostgreSQL or another transactional database behind the API, with BigQuery used later for OLAP-style analytics, reporting, and population-level insight.

The architecture

The architecture was simple because it had to be:

The important design choice was separating rule-based safety from generative assistance. If a danger sign is present, the referral path should not wait for an LLM to reason about it. The model can help structure messy input and support review, but the safety floor should be boring, explicit, and testable.

What the buildathon made obvious

The event compressed a familiar engineering lesson into two hours: most prototypes fail because the scope is vague, not because the tooling is weak.

With AI-native development tools, it is tempting to start generating code immediately. That works for boilerplate, but it does not decide what the system is allowed to be. The human work is still in the framing:

• What is the smallest complete story?
• Which decision must be deterministic?
• Which part can safely be model-assisted?
• What does the backend own?
• What does the frontend own?
• What must be visible in the demo for the idea to make sense?

For Sentinel Health, the smallest complete story was not “AI healthcare”. It was intake, review, urgent referral, and district visibility.

That is where fundamentals helped. Because I had already internalised basic product scoping, API boundaries, data flow, cloud deployment, and safety constraints, the AI tooling had something concrete to accelerate. The speed came from the combination: clear specification first, assisted implementation second.

Prototype, not product

This is worth stating clearly: Sentinel Health was a buildathon prototype, not clinical software.

It was not validated, not production-ready, and not something that should be deployed in a real care setting. Real health software requires clinical review, regulatory work, safety testing, local-language evaluation, privacy assessment, user research, and deployment trials with actual health workers.

The value of the prototype was narrower and more useful: it showed that a complete workflow could be sketched quickly, and it exposed the design boundaries that would matter if the idea were ever taken further.

After the event

I later documented Sentinel Health in my portfolio work on thamu.dev, and the original portfolio update was captured in GitHub PR #56: Buildathon SA 2026 (Sentinel Health, 1st), opened on 11 May 2026.

The project repository is here:

github.com/ThamuMnyulwa/buildathon-60min-2026

The portfolio PR is here:

github.com/ThamuMnyulwa/thamu-dev/pull/56

Sentinel Health placed first at Google Buildathon Southern Africa 2026.

The lesson I kept

The main lesson was not that AI makes everything easy. It does not.

The lesson was that a tight, spec-driven loop can be extremely powerful: define the user, write the spec, turn it into a PRD, split the system into backend and frontend responsibilities, constrain the safety model, build the smallest end-to-end path, deploy it somewhere real, and let the working prototype tell you what the next question should be.

That is a useful habit beyond hackathons. Especially in AI projects, where impressive demos are easy and coherent systems are much harder. AI-assisted programming can move an idea to a POC incredibly fast, but the quality of that POC still depends on the fundamentals underneath it.