Sentinel Health: Wie ich mit spec-driven Entwicklung den Google Build with AI Buildathon Southern Africa 2026 gewonnen habe

Am Donnerstag, dem 30. April 2026, von 17:00 bis 19:00 SAST, nahm ich am Google Build with AI Buildathon Southern Africa teil. Es war ein virtuelles Event, veranstaltet von GDG und dem Developer Ecosystem SSA Team. Die Aufgabe war bewusst eng gefasst: ein vorgegebenes Problem verstehen, eine Loesung entwerfen, schnell bauen und etwas Vorzeigbares zeigen.

Mein Projekt, Sentinel Health, belegte den ersten Platz.

Das Ergebnis war erfreulich, aber der eigentlich interessante Teil war der Prozess. Der Buildathon wurde zu einem kompakten Test fuer spec-driven development: von einer Idee zu einer klaren Spezifikation, von dort zu einer kleinen PRD und dann zum Build mit Backend, Frontend und einem deploybaren Pfad.

Die wichtigste Erkenntnis war nicht einfach, dass KI-gestuetzte Programmierung schnell ist. Sie wird erst dann wirklich stark, wenn die Grundlagen bereits stehen: ein klarer Nutzer, ein eingegrenzter Workflow, eine Backend-/Frontend-Grenze, ein Sicherheitsmodell und ein klares Cloud-Deployment-Ziel.

Der Presentation Room fuer den Google Buildathon Southern Africa 2026.

Die Aufgabe und die Spezifikation

Der Problemraum war Community Health in ländlichen Regionen. Der Nutzer, fuer den ich entworfen habe, war ein Community Health Volunteer, der Patientendaten erfassen, dringende Faelle erkennen und einem Distrikt-Team einen Ueberblick ueber eingehende Faelle geben muss.

Der Prototyp drehte sich fuer mich um eine Frage:

Koennen wir die Aufnahme fuer eine Community Health Worker schneller machen und gleichzeitig sicherheitskritische Entscheidungen deterministisch und nachvollziehbar halten?

Diese Rahmung war wichtig. Ohne sie waere das Projekt leicht in eine unsichere “KI-Diagnose”-Demo abgedriftet. Sentinel Health war das nicht. Die Spezifikation war enger: Intake, Triage-Unterstuetzung, Referral-Signalisierung und Distrikt-Transparenz.

Von der Spezifikation zur PRD und zum Build

Der erste sinnvolle Schritt war nicht Code. Es war, die kurze Aufgabenstellung in eine kleine PRD zu ueberfuehren.

In einem 60-Minuten-Build wirkt das Schreiben einer PRD erst einmal teuer. In der Praxis spart es Zeit, weil es vage Absichten in konkrete Entscheidungen uebersetzt. Ich habe damit folgende Punkte explizit gemacht:

• Der Nutzer ist ein Community Health Volunteer, kein Arzt.
• Spracheingabe kann helfen, ein Formular vorzufuellen, aber ein Mensch muss die strukturierten Felder pruefen.
• Gefahrensignale sollen durch deterministische Regeln erkannt werden, nicht durch Modellurteile.
• Der KI-Pfad ist Entscheidungsunterstuetzung, keine Diagnose.
• Die Demo braucht einen kompletten Loop: Intake, Review, Referral-Signal und Distrikt-Dashboard.
• Die Implementierung braucht Backend und Frontend, nicht nur eine Prompt-Demo.

Diese PRD wurde dann zum Bauplan. Das Backend uebernahm Intake, Regeln, Modellaufrufe, Persistenz und API-Vertraege. Das Frontend uebernahm Spracheingabe/Formularerfassung, Review und das Distrikt-Dashboard. Sobald diese Aufteilung klar war, konnte KI-gestuetzte Programmierung beim Erzeugen und Iterieren von Code helfen, ohne das Produktbild immer wieder neu verhandeln zu muessen.

Was Sentinel Health getan hat

Am Ende der Stunde zeigte der Prototyp einen kompletten Workflow auf beiden Seiten des Systems:

• Ein React-Frontend fuer sprachgestuetzte und formularbasierte Erfassung.
• Ein FastAPI-Backend fuer Case Submission und Modellaufrufe.
• Gemini-gestuetzte Extraktion, um chaotischen Intake-Text in strukturierte Felder fuer das Review zu ueberfuehren.
• Deterministische Regeln fuer Gefahrensignale zur dringenden Weiterleitung.
• Gemini-gestuetzte Triage-Unterstuetzung fuer nicht-kritische Faelle.
• Eine Offline-Queue, um unzuverlaessige Konnektivitaet zu simulieren.
• Ein Distrikt-Dashboard mit Fallfluss, dringenden Referrals und Warnschwellen.
• BigQuery-gestuetzte Event-Speicherung, damit Intake-Events fuer Analyse genutzt werden koennen.

Die Cloud-Oberflaeche war bewusst pragmatisch: Cloud Run fuer Frontend und Backend, BigQuery fuer Events, Secret Manager fuer backendseitige Secrets, Cloud Build und Artifact Registry fuer Deployment sowie Cloud Logging fuer grundlegende Sichtbarkeit.

Containerisiert fuer eine real deploybare Demo

Ein Detail war wichtiger, als es auf den ersten Blick wirkt: Sowohl Backend als auch Frontend mussten in Docker-Containern laufen. Das Ziel war nicht nur, lokal Code zu zeigen. Das Ziel war, den Judges einen deployed POC vorzufuehren, damit sie die Anwendung selbst oeffnen, durch den Workflow klicken und mit der Loesung interagieren konnten.

Das bedeutete, das System in zwei unabhaengig deploybare Cloud-Run-Services aufzuteilen:

• Ein Backend-Container mit FastAPI.
• Ein Frontend-Container mit der React-Anwendung.

Diese Trennung machte die Demo sauberer. Das Frontend konnte sich auf Intake, Review und Dashboard-Interaktion konzentrieren, waehrend das Backend API-Vertrag, Triage-Workflow, Modellaufrufe, Regeln und Persistenz uebernahm. So konnte jede Seite als eigener Service gebaut, deployt und verstanden werden, statt den gesamten Prototyp als eine einzige lokale Demo zu behandeln.

Auf dem Backend verwendete ich FastAPI mit Pydantic-Schemas fuer Ingress und Egress. Damit bekam die Anwendung ein klares Datenmodell: Requests an die API mussten einem expliziten Schema entsprechen, und Responses aus der API mussten fuer das Frontend vorhersehbar strukturiert sein. In einem Projekt mit KI-generiertem oder KI-gestuetztem Code ist diese Grenze wichtig. Sie gibt dem Modell einen klaren Vertrag, gegen den es bauen kann, und dem Menschen etwas Konkretes zum Pruefen.

BigQuery war eine pragmatische Wahl fuer den Buildathon, weil es verfuegbar, vertraut und fuer den Umfang des Prototyps praktisch kostenlos war. Fuer eventbasierten Speicher und Downstream-Analyse war es fuer die Demo gut genug. Fuer eine echte Produktionsanwendung wuerde ich BigQuery jedoch nicht als primaeres transaktionales Backend behandeln. Patient Intake, Case State, Review Status, Referral Status und operative Updates sind OLTP-Themen. Eine produktive Version bräuchte PostgreSQL oder eine andere transaktionale Datenbank hinter der API, waehrend BigQuery spaeter fuer OLAP-Analysen, Reporting und Populationssicht genutzt werden sollte.

Die Architektur

Die Architektur war einfach, weil sie einfach sein musste:

Architektur-Workflow von Sentinel Health.

Die wichtige Designentscheidung war, regelbasierte Sicherheit von generativer Unterstuetzung zu trennen. Wenn ein Gefahrensignal vorhanden ist, darf der Referral-Pfad nicht darauf warten, dass ein LLM darueber nachdenkt. Das Modell kann helfen, unordentliche Eingaben zu strukturieren und das Review zu unterstuetzen, aber die Sicherheitsuntergrenze sollte langweilig, explizit und testbar sein.

Was der Buildathon deutlich gemacht hat

Das Event verdichtete eine bekannte Engineering-Lehre auf zwei Stunden: Die meisten Prototypen scheitern an unklarer Reichweite, nicht an schwacher Technik.

Mit KI-nativen Entwicklungstools ist es verlockend, sofort Code zu generieren. Das funktioniert fuer Boilerplate, entscheidet aber nicht, was das System sein darf. Die eigentliche menschliche Arbeit liegt weiterhin im Framing:

• Was ist die kleinste vollstaendige Geschichte?
• Welche Entscheidung muss deterministisch sein?
• Welcher Teil darf modellgestuetzt sein?
• Was gehoert dem Backend?
• Was gehoert dem Frontend?
• Was muss in der Demo sichtbar sein, damit die Idee verstanden wird?

Fuer Sentinel Health war die kleinste vollstaendige Geschichte nicht “KI im Gesundheitswesen”. Es war Intake, Review, dringende Weiterleitung und Distrikt-Transparenz.

Genau dort halfen die Grundlagen. Weil ich bereits saubere Produktabgrenzung, API-Grenzen, Datenfluss, Cloud-Deployment und Sicherheitsannahmen verinnerlicht hatte, hatte das KI-Tooling etwas Konkretes, das es beschleunigen konnte. Die Geschwindigkeit entstand aus der Kombination: zuerst klare Spezifikation, danach assistierte Implementierung.

Prototyp, kein Produkt

Das sollte klar gesagt werden: Sentinel Health war ein Buildathon-Prototyp, keine klinische Software.

Es war nicht validiert, nicht produktionsreif und nichts, was in einer realen Versorgungssituation eingesetzt werden sollte. Echte Gesundheitssoftware braucht klinische Pruefung, regulatorische Arbeit, Sicherheitstests, Evaluation in lokalen Sprachen, Privacy-Assessment, Nutzerforschung und Feldtests mit echten Health Workern.

Der Wert des Prototyps war enger und trotzdem nützlich: Er zeigte, dass sich ein kompletter Workflow schnell skizzieren laesst, und er machte die Designgrenzen sichtbar, die wichtig waeren, falls man die Idee weiterverfolgen wuerde.

Nach dem Event

Spaeter dokumentierte ich Sentinel Health auch in meinem Portfolio auf thamu.dev, und das urspruengliche Portfolio-Update wurde in GitHub PR #56 festgehalten: Buildathon SA 2026 (Sentinel Health, 1st), eroeffnet am 11. Mai 2026.

Das Projekt-Repository ist hier:

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

Der Portfolio-PR ist hier:

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

Sentinel Health belegte den ersten Platz beim Google Buildathon Southern Africa 2026.

Die Lektion, die ich mitgenommen habe

Die Hauptlektion war nicht, dass KI alles einfach macht. Das tut sie nicht.

Die Lektion war, dass ein enger, spec-driven Loop sehr stark sein kann: den Nutzer definieren, die Spezifikation schreiben, daraus eine PRD machen, das System in Backend- und Frontend-Verantwortung aufteilen, das Sicherheitsmodell begrenzen, den kleinsten End-to-End-Pfad bauen, ihn irgendwo real deployen und den funktionierenden Prototypen die naechste Frage beantworten lassen.

Das ist weit ueber Hackathons hinaus nuetzlich. Besonders in KI-Projekten, in denen eindrucksvolle Demos leicht sind und kohärente Systeme deutlich schwieriger. KI-gestuetzte Programmierung kann eine Idee unglaublich schnell zu einem POC machen, aber die Qualitaet dieses POCs haengt weiterhin von den Grundlagen darunter ab.