13 Projekte in Produktion: Was ich in 1,5 Jahren über KI gelernt habe

Ich habe nicht geplant, 13 Projekte zu bauen. Das erste entstand aus einer konkreten Notwendigkeit: Ein Golfclub brauchte ein digitales Tool, das am Markt so nicht existierte. Also habe ich es gebaut. Das zweite Projekt kam, weil ich beim ersten etwas gelernt hatte, das ich woanders anwenden wollte. Und so weiter.

Jetzt, 1,5 Jahre später, laufen 13 Projekte produktiv. Auf deutschen Servern, DSGVO-konform, mit echten Nutzern. Kein Portfolio-Füller, keine Demos. Alles in Betrieb.

Was ich dabei gelernt habe, ist nichts, was man in Kursen hört.

Das erste Projekt ist immer das schwierigste

Nicht wegen der Technik. Sondern weil man noch nicht weiß, was man nicht weiß. Ich habe beim ersten Projekt Entscheidungen getroffen, die ich heute anders treffen würde. Datenbank-Schema zu eng gedacht. Deployment zu manuell. Kein Monitoring.

Aber das Projekt hat funktioniert. Und das war das Wichtigste.

Die häufigste Falle, in die ich hätte tappen können: wochenlang planen, statt anzufangen. KI-Entwicklung funktioniert anders als klassische Softwareentwicklung. Die Werkzeuge verändern sich schneller, als jeder Plan Bestand hätte. Lernen passiert beim Bauen, nicht beim Vorbereiten.

Die wichtigste Erkenntnis: Infrastruktur kommt vor Features

Klingt banal. Ist es nicht.

Nach dem dritten Projekt hatte ich drei unterschiedliche Deployment-Prozesse, drei verschiedene Monitoring-Setups, und jedes Mal wenn ich eine neue App deployete, war es ein kleines Abenteuer. Keine bösen Überraschungen, aber eben auch keine Routine.

Ab Projekt vier habe ich umgestellt. Einheitliche Serverstruktur. Standardisierter Deploy-Workflow. Features kommen erst, wenn das Fundament steht.

Der Unterschied war sofort spürbar. Nicht in der Geschwindigkeit des ersten Deploys, sondern danach. Debugging geht schneller, wenn alle Apps nach demselben Muster funktionieren. Support geht schneller, wenn ich weiß, wo ich suchen muss. Und neue Projekte starten stabiler, weil das Fundament schon steht.

108 automatische Prüfungen bei jedem Commit

Irgendwann hatte ich genug von Fehlern, die sich hätten verhindern lassen. Keine katastrophalen Bugs, aber die kleinen Dinge: ein fehlender Datenbankindex, eine vergessene Umgebungsvariable, eine Route ohne Authentifizierung.

Ich habe angefangen, automatische Guards zu schreiben. Skripte, die bei jedem Commit prüfen, ob bestimmte Bedingungen erfüllt sind. Heute sind es 108 solcher Prüfungen.

Das klingt nach Overhead. Ist es nicht. Es sind Minuten Arbeit, die mir Stunden ersparen. Wenn ein Guard anschlägt, weiß ich genau, was fehlt. Wenn er nicht anschlägt, kann ich deployen, ohne dreimal nachzudenken.

Diese Guards sind auch ein Gedächtnis. Sie dokumentieren Fehler, die ich einmal gemacht habe, und sorgen dafür, dass ich sie kein zweites Mal mache. Das ist vielleicht die unromantischste Form von KI-Entwicklung. Aber sie funktioniert.

Warum ich lokale Modelle ernst nehme

Ich nutze Cloud-APIs. GPT-4, Claude, Gemini. Ich halte sie für gut und ich zahle gerne dafür. Aber ich bin nicht bereit, meine Infrastruktur vollständig davon abhängig zu machen.

Nicht aus ideologischen Gründen. Aus praktischen.

API-Preise ändern sich. Modelle werden deprecated. Rate-Limits treten genau dann ein, wenn man sie am wenigsten braucht. Und für manche Anwendungsfälle, besonders wenn es um sensible Daten geht, kommt ein externer API-Call schlicht nicht infrage.

Ich betreibe auf meinem Server lokale Modelle parallel. Für bestimmte Aufgaben, für Fallback-Szenarien, für Fälle, wo Datenschutz vor Leistung geht. Die Qualität ist nicht überall gleich gut. Aber die Unabhängigkeit hat einen echten Wert.

Single-Tenant: warum jeder Kunde sein eigenes System bekommt

Alle meine produktiven Deployments sind Single-Tenant. Jeder Kunde hat seine eigene Datenbank, seinen eigenen Container, seine eigene URL.

Viele würden das als Skalierungsproblem betrachten. Für mein Modell ist es das Gegenteil.

Wenn ein Kunde ein Problem hat, beeinflusst es niemand anderen. Wenn ich ein Update einspiele und es läuft nicht, ist das isoliert. Wenn ein Kunde besondere Anforderungen hat, kann ich sie ohne Rücksicht auf andere umsetzen.

Der Preis dafür ist etwas mehr Infrastrukturaufwand pro Neuinstallation. Den zahle ich gerne.

Was ich unterschätzt habe

Drei Dinge haben mich überrascht, alle in dieselbe Richtung:

Support. Technisch gute Software erzeugt trotzdem Support-Anfragen. Nicht weil die Software schlecht ist, sondern weil Menschen unerwartete Wege finden. Ich habe unterschätzt, wie viel Zeit Support kostet, wenn man keine strukturierten Prozesse dafür hat.

Monitoring. "Läuft" und "läuft gut" sind zwei verschiedene Dinge. Ich habe früh Grafana eingebaut, aber ich habe lange gebraucht, bis ich wirklich verstanden habe, was ich überwachen muss. Latenz, Fehlerquoten, Datenbank-Performance. Das lernt man nicht aus der Dokumentation, das lernt man aus Incidents.

Compliance-Dokumentation. DSGVO und EU AI Act sind nicht kompliziert, wenn man sie von Anfang an mitdenkt. Sie sind aber aufwändig zu dokumentieren. Ich habe unterschätzt, wie viel Zeit es kostet, nachzudokumentieren, was ich gebaut habe. Heute entsteht die Dokumentation parallel zur Entwicklung.

Was ich anders machen würde

Früher auf Standardisierung setzen. Nicht nach dem dritten Projekt, sondern vom ersten an.

Jede Abweichung vom Standard, die ich mir als "das mache ich später sauber" erlaubt habe, ist irgendwann zurückgekommen. Manchmal als kleines Ärgernis, manchmal als halber Tag Aufwand, um alte Strukturen zu begradigen.

Standards fühlen sich zu Beginn wie Einschränkungen an. Sie sind es nicht. Sie sind die Grundlage dafür, dass spätere Entscheidungen schneller gehen.

Der Vorteil, alleine zu entscheiden

Ich bin Solo-Founder. Das hat Nachteile, über die ich nicht schreibe, weil sie bekannt sind. Aber es hat einen echten, strukturellen Vorteil: Ich entscheide ohne Meeting.

Wenn ich merke, dass eine technische Entscheidung falsch war, kann ich sie morgen korrigieren. Kein Abstimmungsprozess, keine Rückwärtspriorisierung. Ich sehe ein Problem, ich behebe es.

Das klingt trivial. Ist es nicht, wenn man die Alternative kennt. In Organisationen, die ich von früher kenne, hätte dieselbe Korrektur Wochen gedauert, weil sie durch mehrere Ebenen hätte genehmigt werden müssen.

KI-Entwicklung verändert sich schnell. Die Fähigkeit, schnell zu reagieren, ist kein kleiner Vorteil. Sie ist der Kern dessen, was für mich in den letzten 1,5 Jahren funktioniert hat.

Was mich jetzt beschäftigt

Dreizehn laufende Projekte bedeuten dreizehn laufende Verpflichtungen. Das ist gut, weil jedes davon echte Nutzer hat. Es ist auch eine Frage, die ich mir öfter stelle: Was davon wächst, was davon ist stabil, und was braucht grundlegende Überarbeitung?

Die Antwort darauf ist nicht immer bequem. Aber sie ist wichtig.

KI-Produktentwicklung ist kein Sprint, der irgendwann endet. Es ist die Frage, was man langfristig betreiben will und wie man das strukturiert. Das habe ich in 1,5 Jahren mehr gelernt als alles andere.