Die meisten Briefings für die Entwicklung einer Diabetes-App sehen ungefähr so aus. Registrierung und Onboarding, Glukoseerfassung, Insulin-Erinnerungen, Wochenberichte, KI-gestützte Auswertungen, ein sicheres Backend und CGM-Anbindung "über eine offizielle API oder ein SDK, sofern verfügbar". Die Liste ist vernünftig. Sie beschreibt ein Produkt, das ein echter Mensch benutzen würde, und jeden einzelnen Punkt darauf gibt es heute in ausgelieferten Apps.
Ihr fehlen allerdings die drei Dinge, an denen sich tatsächlich entscheidet, ob Ihr Produkt je erscheint.
Nichts auf dieser Liste ist falsch. Aber eine Funktionsliste behandelt jeden Punkt als gleich viel Entwicklungsarbeit, und in dieser Kategorie sind drei davon überhaupt keine Entwicklungsarbeit. CGM-Zugang ist eine geschäftliche Partnerschaft. Ein Bolusrechner ist ein regulatorisches Programm. Und "Patienten-App oder Plattform" ist eine Architekturentscheidung, die vor dem ersten Sprint fällt und nicht als Ausbaustufe in Version zwei. Trifft man diese drei richtig, baut die Funktionsliste sauber darauf auf. Trifft man sie falsch, verbringt man ein Jahr damit, Fundamente neu zu gießen. Dieser Beitrag geht die zehn Funktionen durch, die jede gereifte App hat, und danach die drei Entscheidungen, die darunter liegen.
Kurz gesagt Die zehn Funktionen, die sich lohnen, liegen auf drei Ebenen: Pflichtprogramm (Tagebuch, Gerätesynchronisierung, Berichte fürs Behandlungsteam, geschätzter HbA1c), Unterscheidungsmerkmale (Musteranalyse, KI-Auswertungen, Kohlenhydratschätzung per Foto) und Umfangstreiber (Bolusrechner, Gamification, Praxis-Dashboard). Die CGM-Anbindung ist ein Partnerschaftsproblem. Der Zugang ist beim Hersteller oft partnergebunden und wird in geschäftlichen Zeiträumen ausgehandelt, nicht in Integrationssprints. Schaffen Sie zuerst Nutzen ohne ihn. Ein Bolusrechner verändert Ihre Produktklasse. Er macht aus Wellness-Software etwas, das klinisch belegt werden muss. Planen Sie ihn architektonisch ein. Liefern Sie ihn nicht nebenbei aus. Nur Patienten oder beide Seiten ist eine Architekturentscheidung. Mandantenfähigkeit und Rollenrechte kosten beim Entwurf wenig und beim Nachrüsten viel. Legen Sie die Reihenfolge so, dass eine einzelne Person am ersten Tag etwas davon hat, denn CGM-Zugang und regulatorische Klarheit kommen in einem Takt, den Sie nicht bestimmen.
Pflichtprogramm, das MVP, das sich seine Existenz verdient
Ein Tagebuch mit mehreren Parametern ist der Kern. Nicht nur Glukose, sondern Kohlenhydrate, Insulin, Bewegung und Stimmung in einem gemeinsamen Verlauf. Niemand pflegt zwei Apps parallel. Das Tagebuch muss also der eine Ort sein, an dem der Tag festgehalten wird.
Gerätesynchronisierung ist der Unterschied zwischen einer App, die nach einer Woche liegen bleibt, und einer, die bleibt. Die Ermüdung durch manuelles Eintragen ist real. Glooko ist hier der Maßstab. Sein Wert liegt in der Bandbreite der Messgeräte und CGMs, die es einliest, und genau deshalb zählt die Integrationsfrage mehr als die Oberfläche (siehe Abschnitt 2). Klären Sie zuerst, welche Geräte Ihre ersten Nutzer tatsächlich besitzen.
Berichte fürs Behandlungsteam machen aus dem Tagebuch etwas klinisch Brauchbares. Ein teilbares PDF oder Dashboard, das Glukoseverläufe und Ereignisse zusammenfasst, ist das, was jemand zum Termin beim Diabetologen mitbringt.
Ein geschätzter HbA1c (oder GMI) gibt den Nutzern eine einzige Zahl, die sie verstehen. Sie wird aus dem Glukosemittelwert berechnet, ist günstig zu bauen, sobald die Daten da sind, und sie verankert das ganze Erlebnis emotional. Das ergibt ein stimmiges MVP für ein Projekt zur Glukoseerfassung. Es nützt einer einzelnen Person, ganz für sich, ohne Partnerschaften und ohne regulatorische Fragen. Liefern Sie dieses Stück zuerst aus und entscheiden Sie dann, was sich den nächsten Sprint verdient.
Unterscheidungsmerkmale, woher die Bindung wirklich kommt
Musteranalyse ist der erste echte Schritt über das Protokollieren hinaus. Wiederkehrende Unterzuckerungen nach dem Sport oder Anstiege durch das Dawn-Phänomen zu erkennen, gibt den Nutzern das Gefühl, dass die App für sie arbeitet und nicht bloß Daten aufbewahrt. Fangen Sie mit dem Muster an, das Ihrer ersten Nutzergruppe am schnellsten auffällt.
KI-Auswertungen und dialogfähige Assistenten führen das weiter. Diabetes Cockpit etwa lässt Nutzer ihre eigenen Daten in natürlicher Sprache befragen. "Warum war ich am Dienstag so hoch?" Und es kommt eine begründete Antwort zurück, die auf den eigenen Einträgen beruht und nicht auf einem allgemeinen Tipp.
Mahlzeiten per Foto erfassen samt Kohlenhydratschätzung nimmt die lästigste Aufgabe im Diabetes-Alltag ab. Undermyfork hat seine Identität um das Fotoprotokoll herum gebaut, verknüpft mit dem Glukoseverlauf, und neuere Anbieter wie ChatCGM treiben die bildbasierte Kohlenhydratschätzung weiter. Für eine App zur Insulindokumentation ist das der beste Verbündete. Bessere Kohlenhydratdaten machen jede nachgelagerte Berechnung ehrlicher. Bauen Sie einen dieser Punkte als Prototyp gegen echte Nutzereinträge, bevor Sie sich auf alle drei festlegen.
Umfangstreiber, wirkungsvoll und nicht umsonst
Ein Bolusrechner empfiehlt Insulindosen. Er ist die wertvollste Funktion auf dieser Liste und zugleich die, die verändert, was Sie rechtlich überhaupt bauen. Er bekommt weiter unten einen eigenen Abschnitt.
Gamification meint Serien und Abzeichen, und in mehreren Studien verbessert sie Beteiligung und Wohlbefinden. Ehrlichkeit ist hier angebracht. Die Belege dafür, dass Gamification speziell die Zeit im Zielbereich verbessert, sind noch dünn. Behandeln Sie sie als Motivationsschicht und nicht als klinische Maßnahme, dann versprechen Sie nicht zu viel.
Ein Monitoring-Dashboard für die Praxis macht aus Ihrem Produkt eine zweiseitige Plattform. Diabetes:M Monitor ist ein klares Beispiel für das ärztliche Gegenstück zu einer Patienten-App. Auch das ist eher eine Architekturentscheidung als eine Funktion (Abschnitt 4).
Das sind zehn Funktionen, in Reihenfolge gebracht. Wägen Sie nun die drei Entscheidungen darunter ab, bevor Sie eine einzige davon zuschneiden.
Entscheidung eins: Die CGM-Anbindung ist ein Partnerschaftsproblem, kein API-Problem
Zurück zum ursprünglichen Briefing. "CGM-Anbindung über eine offizielle API oder ein SDK, sofern verfügbar." Dieses kleine sofern verfügbar trägt das gesamte Risiko der Funktion, und den meisten Gründern fällt das erst mitten im Bau auf.
Der Unterschied, auf den es ankommt, ist dieser. An manche Gerätedaten kommt man über offene Entwicklerprogramme, für die man sich anmeldet und gegen die man sofort prototypen kann. Andere Daten liegen hinter partnergebundenem Zugang. Man bewirbt sich, wird als Unternehmen bewertet, und der Zugang wird zu geschäftlichen Bedingungen gewährt oder eben nicht. Zwischen diesen beiden Modellen liegt der Unterschied zwischen einer Integration von zwei Wochen und einer Verhandlung von neun Monaten.
⚠️ Prüfen Sie die aktuellen Bedingungen des Herstellers, bevor Sie sich auf eine bestimmte Regelung verlassen. Große CGM-Hersteller wie Dexcom und Abbott betreiben Entwickler- und Partnerprogramme, aber die genauen Zugangsstufen, Datenumfänge und Zulassungskriterien ändern sich und gehören gegen die jeweils aktuelle Dokumentation geprüft, bevor Sie eine Roadmap darauf festlegen.
Die praktische Folge ist unbequem. Zeitpläne für den CGM-Zugang sind geschäftliche Verhandlungen und keine Integrationssprints. Sie können Investoren keinen Live-CGM-Feed zu einem festen Datum versprechen, weil das Datum nicht Ihres ist. Der Hersteller bewertet Ihr Unternehmen, Ihren Anwendungsfall und Ihr Volumen, bevor er produktiven Zugang gewährt. Dieser Prozess läuft parallel zu Ihrer Entwicklung und oft sehr viel länger.
Bauen Sie die App also so, dass sie vor dem CGM-Zugang wirklich etwas taugt. Drei Datenwege bringen Sie dorthin:
- Manuelle Eingabe, gut gemacht, mit schneller Erfassung und klugen Voreinstellungen.
- Messgerät-Sync über Bluetooth-Blutzuckermessgeräte, deren Zugangshürden in der Regel deutlich niedriger liegen als bei CGMs.
- Import aus dem Gesundheitsspeicher der Plattform, also Glukosedaten abholen, die der Nutzer ohnehin schon nach Apple Health oder in Googles Gesundheitsdienste leitet.
Jeder dieser Wege macht Tagebuch, Berichte und Musteranalyse voll funktionsfähig. Kommt der direkte CGM-Zugang dann, ist er die Aufwertung eines bereits funktionierenden Produkts und nicht das, worauf das Produkt gewartet hat.
Eine Warnung zu Open Source. Community-Projekte, die CGM-Daten nachbauen, sind hervorragende Werkzeuge zum Prototypen. Mit ihnen können Sie Bedienung und Auswertung prüfen, bevor Sie genehmigten Zugang haben. Ein produktiver Weg sind sie nicht. Ein kommerzielles Produkt auf inoffiziellem Zugang zu bauen, ist ein Compliance- und Zuverlässigkeitsrisiko, das Sie nicht in eine Herstellerverhandlung mitnehmen wollen. Nutzen Sie sie zum Lernen und wechseln Sie zum Ausliefern auf genehmigten Zugang. Mit dem genehmigten Zugang zeigen sich auch die echten Grenzen der Daten, und was aus einem CGM-Feed tatsächlich ankommt bestimmt Ihren Funktionsumfang stärker als der Zugangsweg.
Entscheidung zwei: Der Bolusrechner verändert, was Sie bauen
Alles andere auf der Funktionsliste ist, grob gesagt, Wellness-Software. Eine Funktion, die eine Insulindosis empfiehlt, ist das nicht. Das ist die eine Entscheidung, die Gründer beim ersten Gesundheitsprodukt am ehesten kalt erwischt.
Sehen Sie sich an, wie ein ernsthafter Anbieter damit umgeht. Diabetes:M liefert einen Bolus-Assistenten aus, schränkt diese Funktion in Märkten wie den USA und Australien ein und hat im Juli 2025 eine klinische Studie gestartet, die eigens den Rechner untersucht. Lesen Sie das genau. Ein etabliertes, ausgeliefertes Produkt behandelt eine einzelne Funktion als laufendes klinisches Programm mit geografischen Einschränkungen. Das sagt mehr als jede Zitierung einer Verordnung. Ein Dosisrechner ist kein Sprint-Ticket. Er ist ein Arbeitsstrang mit eigener Evidenz und eigener Freigabe je Markt.
⚠️ Wie eine dosisbezogene Funktion regulatorisch eingestuft wird, hängt von der Rechtsordnung und der Zweckbestimmung ab. Holen Sie eine qualifizierte regulatorische Prüfung ein, bevor Sie Aussagen über den Status Ihres Produkts treffen oder bestimmte Geräteklassen benennen.
Für Ihren Bau lässt sich das schlicht fassen:
- Bauen Sie zuerst die Protokoll- und Auswertungsschicht. Kohlenhydratdaten, Insulinverlauf und Glukosemuster nützen schon für sich und sind genau die Daten, die ein Rechner später bräuchte.
- Planen Sie so, dass sich die Dosisberechnung hinter einem Feature-Flag ergänzen lässt, idealerweise regional schaltbar, damit Sie sie nur dort und dann freigeben, wo Sie dürfen.
- Behandeln Sie die Einstufung als Entscheidung vor dem ersten Sprint. Ob Sie einen Dosisrechner bauen, bestimmt Ihren regulatorischen Weg, Ihren Dokumentationsaufwand und Ihren Zeitplan. Spät entschieden heißt drumherum neu gebaut.
Die gute Nachricht: Der ganze Rest des Produkts lässt sich bauen, ohne das je anzufassen. Etliche erfolgreiche Diabetes-Apps hören bewusst bei Protokoll, Auswertung und Bericht auf und überlassen die Dosisentscheidung dem Arzt. Das ist ein vollwertiges Produkt und kein fauler Kompromiss. Legen Sie Ihre Produktklasse fest, bevor Sie das erste Ticket schreiben.
Entscheidung drei: nur Patienten oder beide Seiten?
Das ursprüngliche Briefing beschreibt eine Patienten-App. Doch jedes gereifte Produkt dieser Kategorie hat eine ärztliche Seite, und die International Diabetes Federation fasst das ganze Feld inzwischen als Diabetes-Management-Plattformen. Dashboards, zunehmend KI-gestützt, die Daten aus mehreren Geräten zusammenführen, damit Behandelnde darauf reagieren können.
Für Ihre Roadmap ist der Punkt eindeutig. Das ist eine Architekturentscheidung und keine Funktion für Version zwei. Besteht auch nur die Möglichkeit, dass ein Dashboard für Behandelnde dazukommt, muss das Fundament jetzt liegen. Drei Dinge sind im Entwurf billig und im Nachrüsten schmerzhaft:
- Mandantenfähigkeit, also dass eine Praxis viele Patienten verwalten kann, bei strikter Datentrennung zwischen Organisationen.
- Einwilligung und Freigabemodelle, ausdrücklich, widerrufbar und nachvollziehbar, damit ein Patient Daten an eine bestimmte Praxis freigeben kann.
- Rollenbasierte Zugriffssteuerung, mit sauber abgegrenzten Rollen für Patient, Behandelnde, Verwaltung und Support.
Das in ein System nachzurüsten, das für eine einzelne Person entworfen wurde, heißt: Datenmodell, Authentifizierung und die gesamte Rechtelogik neu bauen. Vorab kostet es ein paar zusätzliche Entwurfsgespräche und einige bewusste Schemaentscheidungen.
Es verändert außerdem das Geschäftsmodell, und das ist der Teil, der Gründer am meisten beschäftigt. Diabetes-Apps für Endkunden monetarisieren langsam. Die ärztliche Seite, also Praxen und Versorger, die für Populationsdashboards und Fernüberwachung zahlen, ist meist die Seite mit dem Umsatz. Sich für "vorerst nur Patienten" zu entscheiden, ist völlig in Ordnung. Sich aus Versehen dafür zu entscheiden, weil niemand die Frage gestellt hat, ist der Weg zum Neubau im zweiten Jahr. Wenn Sie diese Abwägung vor sich haben: Genau dafür gibt es unsere Praxis für Gesundheitswesen und Beratung. Stellen Sie die Frage nach der zweiten Seite laut, bevor der Entwurf beginnt.
Was KI hier tatsächlich leistet
"KI-gestützte Auswertungen" ist die vageste Zeile in jedem Briefing für eine Diabetes-App. Zieht man das Marketing ab, bleiben vier konkrete Aufgaben, jede davon ein echtes, abgrenzbares Stück Entwicklung:
- Kohlenhydrate aus Mahlzeitenfotos schätzen, also Bildverarbeitung, die aus dem Foto eines Tellers einen Kohlenhydratwert macht. Wirklich schwer, wirklich wertvoll, und das Unterscheidungsmerkmal hinter Produkten wie Undermyfork und ChatCGM.
- Muster über Glukose- und Kontextdaten hinweg erkennen, also Zusammenhänge zwischen Glukose und Essen, Schlaf oder Tageszeit sichtbar machen, die von Hand niemand findet.
- Die eigene Historie in natürlicher Sprache befragen, sodass jemand fragen kann "wie reagiere ich normalerweise auf Pasta?" und eine Antwort bekommt, die auf den eigenen Einträgen beruht, so wie es Diabetes Cockpit macht.
- Berichte erzeugen, also saubere, klinisch lesbare Zusammenfassungen für Termine, automatisch.
Beachten Sie, was nicht auf der Liste steht. Eigenständige Therapieempfehlungen. Die Kategorie hat sich auf KI festgelegt, die Berichte und Hinweise erzeugt, und nicht auf KI, die Ihnen sagt, wie viel Insulin Sie spritzen sollen. Genau an dieser Linie, zwischen eine Entscheidung stützen und eine Entscheidung treffen, verläuft die regulatorische Grenze. Es ist dasselbe Argument wie beim Bolusrechner, nur von der KI-Seite betrachtet. Die vier Aufgaben oben zu bauen ist eine gut verstandene Entwicklung eines individuellen KI-MVP. Der Schritt zur eigenständigen Dosierung ist ein klinisches Programm. Halten Sie beides in der Planung auseinander und schneiden Sie zuerst nur die Berichtsseite zu.
Die Reihenfolge eines Baus
Legt man das alles zusammen, schreibt sich die Reihenfolge von selbst. Drei Phasen, jede auslieferbar, jede nützlich, bevor die nächste beginnt:
Phase 1, Protokoll und Berichte. Das Tagebuch mit mehreren Parametern, Eingabe von Hand und über Messgeräte, der geschätzte HbA1c und teilbare Berichte fürs Behandlungsteam. Das nützt einer einzelnen Person am ersten Tag, ohne Partnerschaften und ohne regulatorische Fragen. Es ist außerdem das Datenfundament, das alles Weitere braucht.
Phase 2, Gerätesynchronisierung und Musteranalyse. Import aus dem Gesundheitsspeicher, Bluetooth-Messgeräte und, sobald die Zugangsverhandlungen abgeschlossen sind, die direkte CGM-Anbindung, darunter die Mustererkennung. Weil der CGM-Zugang im Takt des Herstellers eintrifft, muss Phase 1 ohne ihn für sich stehen.
Phase 3, KI-Schicht und Praxis-Dashboard. Kohlenhydratschätzung per Foto, dialogfähige Abfragen, automatische Berichte und, falls Ihre Architekturentscheidung dorthin zeigte, die Plattform für Behandelnde.
Das Ordnungsprinzip ist einfach. Lassen Sie den Nutzen Ihres Produkts nie von etwas abhängen, das Sie nicht kontrollieren. CGM-Zugang und regulatorische Klarheit kommen beide im Takt anderer. Bauen Sie so, dass eine echte Person echten Nutzen hat, während Sie darauf warten. Skizzieren Sie Ihre eigenen drei Phasen, bevor Sie eine Zeile Code schreiben.
Die drei Entscheidungen, ein Gespräch
Die zehn Funktionen sind der unkomplizierte Teil. Ob Ihre Diabetes-App tatsächlich erscheint, entscheiden drei Fragen, die die Funktionsliste verdeckt. Ist Ihr CGM-Zugang ein offenes Programm oder eine Partnerverhandlung? Bauen Sie einen Dosisrechner und damit ein klinisches Programm? Und bauen Sie eine Patienten-App oder eine zweiseitige Plattform? Jede davon ist jetzt billig zu beantworten und später teuer.
Das ist das Gespräch, das sich vor dem ersten Sprint lohnt. Als Unternehmen für die Entwicklung von Gesundheits-Apps schneiden wir lieber ehrlich zu, als blind zu kalkulieren. Bringen Sie uns also Ihre Funktionsliste, und wir sagen Ihnen, welche Teile Integrationsarbeit sind, welche Architektur und welche Zusagen auf Programmebene. Starten Sie ein Zuschnittsgespräch mit Ihrer aktuellen Liste und allem, was schon vorliegt, und wir stellen es dem gegenüber, was ein Bau wirklich kostet.
Sie fragen sich, was das in Ihren eigenen Systemen bedeuten würde?
Das Audit kostet nichts, und Sie behalten den Plan samt Kosten und Risiken, ob Sie damit weitermachen oder nicht.
Kostenloses Automatisierungs-Audit buchen
Arun Andiselvam
LinkedInIch bin Gründer und habe fünf Marken aufgebaut. Die erste, ein SEO-Werkzeug, habe ich für einen sechsstelligen Betrag verkauft, und heute entwickle ich KI-Automatisierung für Unternehmen. Jede davon habe ich vom ersten Tag an aus eigener Kraft finanziert.
