Google ran a Buildathon Southern Africa 2026 (part of Build with AI) earlier this year. The format is the whole game: each participant is given a question — a short problem statement — and has 60 minutes to ship something from a blank repo onto Google Cloud. That’s it. The clock is the constraint.

This is the writeup of the build I did, solo. The brief was about community health workers in rural settings — given, not chosen. The prototype placed first on the day, which was a nice surprise, but this post is about the process, not the result.

Important caveat up front: this is a 60-minute prototype, not a production application. Nothing here is clinically validated and nothing should be read as a real solution to anything. The interesting part is how far you can get from a posed problem to a visible, cloud-deployed MVP when the only thing that matters is the clock.

The first 15 minutes: PRD

A surprising chunk of the hour went into writing rather than coding. The first ~15 minutes were spent drafting and refining a PRD: who the user is, what the workflow has to be, what’s in and out of scope, and what the demo needs to show at minute 59. Skip that step and you spend the build phase changing your mind — which means you ship nothing.

The PRD wasn’t long. A page of bullet points naming the user (a community health volunteer), the inputs (voice + structured form), the must-show behaviours (urgent-referral path, AI-assisted triage, district visibility), and the explicit non-goals (no diagnosis, no production deploy story).

The next ~45 minutes: building in Antigravity

I drove the build using Antigravity (Google’s AI-native IDE) as the working environment. It’s solo coding with the model in the loop — intent → generated code → running app, fast enough that you can iterate twice in the time it usually takes to write boilerplate once.

Two services, deployed independently to Cloud Run:

• Backend: FastAPI (Python) — handles intake, calls Gemini, writes events to BigQuery.
• Frontend: React — voice/form intake, the CHV review screen, and the district dashboard.

What got built in the prototype

What was on screen at minute 60:

• Voice-assisted intake — browser speech recognition or on-device Whisper transcription, with Gemini extracting structured fields for a human to review before submission.
• Deterministic danger-sign rules that bypass the model and trigger urgent referral immediately.
• Gemini-assisted triage for non-critical cases — decision support, not diagnosis.
• Offline-style queue and sync to mimic patchy connectivity.
• District dashboard — live case feed, urgent referrals, outbreak-threshold alerts.
• BigQuery-backed event storage so the same intake stream feeds downstream analytics.

Reading that list, it sounds like a product. It isn’t. It’s a demo loop you can show in two minutes — each bullet exists in a state that’s good enough for a live walkthrough and nothing more.

Architecture

Google Cloud surface used: Gemini (intake + triage), Cloud Run (frontend + backend, deployed independently), BigQuery (events + outbreak detection), Secret Manager (backend-only Gemini key), Cloud Build + Artifact Registry (source-based deploys), Cloud Logging.

This is a prototype, not a product

Worth repeating since it’s easy to lose in a writeup that mentions “danger signs” and “referral”: none of this is production code, clinically validated, or deployable in any real care setting. It’s a 60-minute exercise. Real health software needs validation, clinical sign-off, regulatory pathways, and deployment trials with actual users. None of that was — or could be — in scope for the hour.

Where this could go (if I were to take it further)

A few directions worth thinking about if this were more than a one-hour build:

On-device-first architecture. Move triage onto low-cost Android devices using MedGemma and Gemma-family models for clinically-aligned inference: local-language voice intake, multimodal assessment for signs like malnutrition, offline sync with conflict handling, privacy-preserving district analytics, and validation against local protocols.

Human-in-the-loop safety as a design constraint:

• Voice input only prepopulates the form — the CHV reviews and edits before submission.
• Danger-sign detection is deterministic — it does not wait on AI.
• AI output is decision support, not diagnosis.
• District alerts are signals for public-health action, not automated conclusions.

These are starting points, not commitments. Whether any of them get built depends on real users, partners, and the time to do them properly.

Reflection

The most useful thing about a 60-minute build is how brutally it forces scoping. The win condition isn’t make it good — it’s make something visible inside the hour. That changes how you think about prototyping more generally: problem → PRD → cloud-deployed POC can compress into a much tighter loop than most teams give themselves, and the limit is usually willingness to cut scope, not tooling.

Picking the rule-based danger-sign path as the safety floor (rather than gating it on the model) was the design choice that made the demo coherent. Voice + structured extraction + a real cloud-deployed dashboard was the minimum that told a complete story end-to-end.

Mostly, though, it was fun. A short, sharp exercise in how fast you can go from a posed question to something a person can see and click — which is an underrated way to test whether an idea is worth more time.

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