Das Ziel
Ein junges Softwareunternehmen hatte ein CRM mit KI im Kern gebaut. Der Großteil des Codes stammte von KI-Coding-Agenten, die das Team steuerte. Das Produkt funktionierte, und Kunden nutzten es bereits täglich.
Sie haben uns mit 3 Aufgaben beauftragt. Das CRM prüfen, die Infrastruktur darunter instand setzen und ein agentisches System bauen, das Dokumente liest, Erkenntnisse daraus zieht und mit KI neue Dokumente erstellt. Diese Seite behandelt die ersten beiden. Das agentische System ist ein eigenständiges Produkt und bekommt deshalb eine eigene Fallstudie.
Die Schwachstellen
Das Produkt war gut. Das Fundament darunter war nicht bereit zu wachsen.
- Entwicklung und Produktion liefen nebeneinander. Es gab keine klare Grenze zwischen dem Ort, an dem Funktionen gebaut wurden, und dem, an dem Kunden arbeiteten.
- Die Entwicklung arbeitete mit Echtdaten. Die Entwicklungsumgebung hatte keine eigene Datenbank, also lief jeder Test auf echten Kundendatensätzen.
- Die Server liefen voll. Vorschau-Builds und hochgeladene Bilder füllten die Festplatte des VPS (eines gemieteten virtuellen Servers). Jemand löschte alte Builds und veraltete Dateien von Hand, damit alles weiterlief.
- Deployments waren schwierig. Man musste die Eigenheiten jedes Servers kennen, um eine Änderung sicher auszuliefern.
- Bugs erreichten die Kunden. Es gab keine Release-Pipeline. Die Tests existierten, aber nichts ließ sie vor dem Livegang bei jeder Änderung laufen.
Das KI-Coding-Setup dagegen war eine angenehme Überraschung. Klare Dokumentation, klare Regeln für die Agenten und testgetriebene Entwicklung, bei der die Tests vor dem Code geschrieben werden. Es musste nicht neu gebaut werden. Es brauchte Feinschliff.
Was wir getan haben
1. Das KI-Coding-Setup verfeinert
KI-Agenten lesen die Projektdokumente, bevor sie eine einzige Zeile Code schreiben. Jede gelesene Zeile kostet Tokens, die Einheit, nach der KI-Anbieter abrechnen, und prägt ihre Entscheidungen. Wir haben 2 Probleme gefunden.
- Die Dokumente waren zu lang geworden. Manche Leitfäden hatten über 1.000 Zeilen. Wir haben sie auf das gekürzt, was ein Agent für eine bestimmte Aufgabe wirklich braucht.
- Alte Tickets blieben in den Aufgabenlisten. Erledigte Arbeit stand noch in den TODO-Dateien, sodass die Agenten weiter über längst behobene Bugs lasen, und dieser veraltete Kontext landete in jeder Sitzung. Wir haben die erledigte Arbeit ausgelagert, jetzt erreichen nur noch offene Aufgaben die Agenten.
Außerdem haben wir Skills hinzugefügt, wiederverwendbare Anweisungen für wiederkehrende Aufgaben, und die Agenten mit den Tools verbunden, die sie täglich nutzen, etwa GitHub. Weniger Lesen pro Aufgabe. Niedrigere Token-Rechnungen.
2. Entwicklung und Produktion getrennt
Wir haben eine klare Grenze zwischen 3 Umgebungen gezogen:
| Umgebung | Wo sie läuft | Wofür sie da ist |
|---|---|---|
| Entwicklung | Der bestehende VPS | Agenten schreiben Code und sehen sich ihre Arbeit in der Vorschau an |
| Staging (Vorabumgebung) | Der bestehende VPS, mit eigener Datenbank | Jede Änderung wird vor dem Release vollständig getestet |
| Produktion | Railway, hinter Cloudflare | Nur für Kunden |
Entwicklung und Staging haben jetzt eigene Daten, niemand testet mehr mit echten Kundendatensätzen. Änderungen bewegen sich nur in eine Richtung: Entwicklung, dann Staging, dann Produktion.
3. Die Produktion ohne Stillstand in die Cloud verlegt
Rund 20 GB an Dateien lagen auf einem einzelnen VPS. Wir haben alles nach AWS S3 verschoben, dem Cloud-Speicher von Amazon, während die Kunden das Produkt weiter nutzten.
Wir haben es nicht auf einen Schlag gemacht. Die Dateien wurden in Etappen verschoben, wir haben die Produktionsdatenbank kopiert und bei jedem Schritt Backups angelegt. Nur die finale Umstellung brauchte ein kurzes, geplantes Wartungsfenster. Seitdem läuft die Produktion überhaupt nicht mehr auf einem VPS. Sie läuft auf Railway, einer Cloud-Hosting-Plattform, mit Cloudflare davor für das Netzwerk und S3 für Dateien und Backups.
Um Speicherplatz muss sich jetzt niemand mehr kümmern.
4. Eine Release-Pipeline gebaut, die Bugs stoppt, fast kostenlos
Als wir ankamen, gab es kein CI/CD, also haben wir es gebaut. CI/CD (Continuous Integration und Continuous Delivery) ist eine automatisierte Pipeline: Jede Änderung durchläuft die komplette Testsuite, und nur Änderungen, die bestehen, werden ausgeliefert. Der kostenlose GitHub-Plan enthält 2.000 Minuten GitHub Actions pro Monat, jede weitere Minute kostet Geld. Alle Unit-, Integrations- und End-to-End-Tests bei jeder Änderung laufen zu lassen, würde dieses Kontingent schnell aufbrauchen.
Für ein Startup ist jeder Euro, den man nicht ausgibt, ein Euro, den man behält. Deshalb haben wir den schweren Teil der Pipeline auf den VPS verlegt, den das Team ohnehin bezahlte. Dort läuft die komplette Testsuite, auf Staging. GitHub Actions übernimmt nur die letzten Schritte, etwa 5 Minuten pro Release statt jedes Mal eines kompletten Testlaufs.
Früher landeten viele Bugs in der Produktion. Heute sind es kaum noch ein oder zwei, weil die Pipeline sie vorher auf Staging abfängt.
Vorher und nachher
| Vorher | Nachher | |
|---|---|---|
| Hosting | Entwicklung und Produktion auf VPS-Servern, mit einer gemeinsamen Datenbank | Railway für die Produktion, VPS für Entwicklung und Staging |
| Daten | Entwicklung mit der Produktionsdatenbank verbunden | Jede Umgebung hat ihre eigene Datenbank |
| Dateien | Auf der Serverfestplatte, von Hand aufgeräumt | AWS S3, mit Backups |
| Netzwerk | Direkt auf den Servern | Cloudflare davor |
| Releases | Keine Pipeline, häufige Bugs in der Produktion | CI/CD mit kompletter Testsuite auf Staging, etwa 5 Minuten auf GitHub Actions, kaum noch Bugs in der Produktion |
| KI-Coding-Setup | Gut, aber lange Dokumente und veraltete Tickets | Kurze Dokumente, nur offene Aufgaben, neue Skills und Tools |
Das Ergebnis
Das CRM läuft jetzt auf Railway, Cloudflare und AWS S3, einer Infrastruktur, die mitwachsen kann. Die Produktion ist von der Entwicklung getrennt, Kundendaten bleiben, wo sie hingehören, und die Verfügbarkeit liegt über 99 %. Das Produkt ist sicher, stabil und bereit, sich bei vielen weiteren Kunden zu bewähren.
Das Team liefert auch schneller. Die Agenten lesen weniger und schaffen mehr, und jede Änderung besteht die komplette Testsuite, bevor ein Kunde sie zu sehen bekommt.
Was wir gelernt haben
Wer etwas von null aufbaut, muss es bauen, nicht planen. Erst einmal zum Laufen bringen. Genau das hat dieses Team getan, und es hatte recht.
Etwas zu reparieren, das funktioniert, ist viel leichter, als das perfekte Tool vom ersten Tag an zu planen. Vom Start aus sieht man nie das Ende des Weges. Man sieht das nächste Stück, während man vorangeht, und das reicht. Sobald es läuft, automatisiert man, verbessert und justiert nach. Genau das haben wir hier getan. Wir haben ihr Produkt nicht neu gebaut. Wir haben ein gutes Produkt bereit gemacht, sicher zu wachsen.
Ist Ihr Produkt schneller gewachsen als sein Fundament? Buchen Sie ein 30-minütiges Gespräch und wir sehen uns Ihr Setup gemeinsam an.