Wie ich ohne klassische Entwicklerlaufbahn eine SaaS gebaut habe - mit KI und QA-Mindset

Die Idee zu NutriKompass entstand nicht aus einem typischen Startup-Brainstorming, sondern aus einem sehr konkreten Problem. In therapeutischen Einrichtungen für Jugendliche mit Essstörungen dreht sich ein großer Teil der täglichen Arbeit um Essensplanung, Einkaufslisten, Dokumentation und organisatorische Abstimmung.

Vieles davon lief noch manuell über Papier, Excel oder Word, obwohl im Alltag kaum Zeit dafür bleibt. Als ich das gesehen habe, war mein erster Gedanke nicht: Man müsste eine App gründen. Ich dachte schlicht: Das müsste sich doch sinnvoll automatisieren lassen.

Ich bin kein klassischer Softwareentwickler. Beruflich komme ich aus IT-Consulting, Testmanagement, Qualitätssicherung und Release-Management. Ich hatte immer ein gutes Gefühl dafür, was technisch möglich ist, aber ich war lange niemand, der komplette Anwendungen selbst baut.

Genau deshalb war NutriKompass für mich anfangs eher ein Experiment als ein sicherer Plan. Eine kleine lokale Lösung hätte ich mir noch vorstellen können. Aber eine echte Web-Anwendung mit Datenbank, Login, Zahlungsabwicklung und produktionsnahen Abläufen wirkte zunächst deutlich zu groß.

Mein erster Schritt war deshalb nicht, direkt loszuprogrammieren. Ich habe zunächst mit verschiedenen KI-Systemen über die Idee gesprochen: Gibt es dafür überhaupt einen echten Bedarf? Welche Architektur wäre sinnvoll? Welche Technologien passen zu einer solchen Anwendung? Welche Risiken müsste ich früh mitdenken?

Tools wie Codex, ChatGPT und CloudCode waren für mich in dieser Phase weniger Code-Generatoren als Sparringspartner. Sie haben mir geholfen, Annahmen zu prüfen, Optionen zu vergleichen und schneller von einer vagen Idee zu einer belastbaren Produktvorstellung zu kommen.

Im weiteren Verlauf habe ich selten nur mit einem Modell gearbeitet. Mein Workflow bestand oft darin, ein Problem zu beschreiben, mir Lösungsvorschläge von mehreren Systemen geben zu lassen, die Ergebnisse zu vergleichen und einzelne Implementierungen gegenseitig prüfen zu lassen. So entstand über die Zeit eher ein kleines KI-Team als ein einzelnes Werkzeug.

Besonders hilfreich war dabei, dass ich Code nicht einfach übernommen habe. Ich habe Reviews zwischen Modellen genutzt, alternative Umsetzungen gegeneinander gestellt und Prompts bewusst überarbeitet. Ein wichtiger Hebel war für mich außerdem ein eigener Prompt-Optimierer, der aus einer groben Idee zuerst eine saubere Arbeitsanweisung gemacht hat, bevor ein Modell überhaupt mit dem Coden begann.

Eine der wichtigsten Erkenntnisse war für mich schnell: KI kann sehr viel Code generieren, aber sie macht auch regelmäßig Dinge kaputt. Nach Änderungen funktionierten plötzlich Features nicht mehr, bestehende Abläufe wurden instabil oder kleine Seiteneffekte blieben zunächst unsichtbar.

Genau hier war mein Hintergrund in Qualitätssicherung entscheidend. Ich habe früh automatisierte Tests, Smoke-Tests und einfache Qualitätsschleifen eingebaut. Das hat den Unterschied zwischen bloß generiertem Code und einer belastbaren Anwendung gemacht, weil ich nach Änderungen nicht raten musste, sondern automatisiert prüfen konnte, ob die wichtigsten Flows noch intakt sind.

Die größte Herausforderung war am Ende nicht der eigentliche Code, sondern der Rahmen drum herum. Besonders wichtig waren Datenschutzfragen, weil sich das Produkt in einem Gesundheitskontext bewegt: sichere Datenspeicherung, Mandantentrennung und die Frage, welche Informationen überhaupt verarbeitet werden dürfen.

Dazu kam das Thema API-Kosten. Wenn Essenspläne automatisch generiert werden, darf man Requests nicht einfach beliebig wachsen lassen. Ich musste also lernen, Prompts effizient zu formulieren, unnötige Aufrufe zu vermeiden und das Produkt so zu bauen, dass die laufenden Kosten kontrollierbar bleiben. Überraschend einfach waren dagegen UI-Entwicklung, Integrationen und Deployment, sobald die Grundarchitektur sauber stand.

Die ersten Nutzer kamen direkt aus dem therapeutischen Bereich. Das war ideal, weil es sofort echtes Feedback aus dem Alltag gab: individuelle Portionseinstellungen, Anpassungen für einzelne Bewohner und spezifische Planungsoptionen, die man sich am grünen Tisch so nicht ausdenkt. Genau diese Rückmeldungen haben das Produkt schnell besser gemacht.

Mein wichtigstes Learning aus dem Projekt ist deshalb nicht, dass KI Entwickler ersetzt. Für mich zeigt NutriKompass etwas anderes: Wer ein reales Problem gut versteht, sauber denkt, Prompts präzise formuliert und Qualität ernst nimmt, kann heute sehr viel mehr selbst umsetzen als noch vor wenigen Jahren. KI ersetzt keine Produktverantwortung, aber sie macht den Weg von der Idee zur funktionierenden Anwendung deutlich kürzer.