Von der ersten Commit bis zum Live-Produkt in 48 Stunden

21. November 2025, 9:14 Uhr

Das war der Zeitpunkt, an dem wir den ersten Commit gemacht haben. Ein leeres Projekt. Eine leere Leinwand. Bis zum 23. November um Mitternacht hatten wir ein Live-Produkt mit einer benutzerdefinierten Domain, das echten Nutzern diente.

Das ist keine Geschichte über Abkürzungen oder das Versenden von fehlerhafter Software. Es geht darum, was passiert, wenn du genau weißt, was du baust, und keine Zeit mit etwas anderem verschwenden willst.

Was in 48 Stunden geliefert wurde

Das war bis zum Ende des zweiten Tages live:

Eine Echtzeit-AI-Chatoberfläche. Kein Wrapper um eine API. Ein richtiges Chatsystem mit Sitzungsverwaltung, Nachrichtenverlauf und Streaming-Antworten. Nutzer konnten Gespräche mit AI-Agenten führen, die tatsächlich den Kontext erinnerten.

Ein virtuelles Dateisystem. Nutzer konnten Ordner erstellen, Dateien hochladen, umbenennen und in Arbeitsbereiche organisieren. Die AI konnte während der Gespräche auf diese Dateien lesen und schreiben. Keine Spielzeug-Demo — ein echtes Dateisystem, unterstützt von MongoDB.

Arbeitsbereiche mit Agentenwechsel. Verschiedene Arbeitsbereiche konnten unterschiedliche AI-Agenten mit unterschiedlichen Fähigkeiten nutzen. Ein Nutzer konnte einen Programmierarbeitsbereich, einen Schreibarbeitsbereich und einen Forschungsarbeitsbereich haben — jeder mit seinem eigenen Kontext und seinen eigenen Dateien.

Benutzerauthentifizierung und Synchronisation. Verbunden mit unserem Authentifizierungssystem über RabbitMQ. Nutzer loggten sich ein und ihre Daten waren da. Über Geräte hinweg. Sofort.

Bildgenerierung. Die AI konnte während der Gespräche Bilder generieren. Nicht nur Textantworten — tatsächliche visuelle Ausgaben.

Vorlagen. Vorgefertigte Ausgangspunkte, damit Nutzer bei ihrem ersten Besuch nicht vor einem leeren Bildschirm stehen.

Bereitstellungspipeline. Dockerisiert, bereitgestellt, läuft auf einer benutzerdefinierten Domain mit ordnungsgemäßer Umgebungsconfiguration.

Die Entscheidungen, die das möglich gemacht haben

So eine Geschwindigkeit kommt nicht davon, dass man 48 Stunden am Stück arbeitet (obwohl es davon genug gab). Sie kommt von den Entscheidungen, die du triffst, bevor du die erste Codezeile schreibst.

Entscheidung 1: MongoDB statt Mongoose. Wir haben etwa vier Stunden mit Mongoose gestartet. Dann sind wir auf die rohen MongoDB-Treiber umgestiegen. Mongoose fügt eine Schema-Validierungsschicht hinzu, die für große Teams hilfreich ist, aber reiner Overhead für ein kleines Team, das sein Datenmodell kennt. Vier Stunden “verschwendet”, die uns in den folgenden Wochen Dutzende Stunden gespart haben.

Entscheidung 2: Server und Client in einem Repo bauen. Monorepo. Eine docker-compose.yml. Ein Bereitstellungsbefehl. Keine Koordination zwischen Repos. Kein “die API ist bereitgestellt, aber das Frontend nicht.” Wenn du schnell unterwegs bist, ist es wichtiger, die Anzahl der Dinge, die aus dem Takt geraten können, zu reduzieren, als organisatorische Reinheit zu wahren.

Entscheidung 3: Am zweiten Tag in die Produktion schicken, nicht am zwanzigsten. Wir haben bereitgestellt, bevor wir “bereit” waren. Die Domain war konfiguriert, SSL war eingerichtet, Umgebungsvariablen waren vorhanden — alles, bevor die Hälfte der Funktionen gebaut war. Warum? Weil das Bereitstellen der Teil ist, der dich überrascht. Es ist besser, diese Überraschungen am zweiten Tag mit drei Funktionen zu entdecken als am zwanzigsten mit dreißig.

Was wir nicht gebaut haben

Genauso wichtig wie das, was wir geliefert haben, ist das, was wir absichtlich weggelassen haben:

• Kein Admin-Panel. Wir haben MongoDB Compass direkt verwendet.
• Kein benutzerdefiniertes Designsystem. Wir haben saubere Standards verwendet und später iteriert.
• Keine Analytik. Wir haben die Serverprotokolle beobachtet.
• Keine automatisierten Tests. (Das kam am dritten Tag.)
• Keine Dokumentation. Der Code war die Dokumentation.

Jedes dieser Dinge wäre das “verantwortungsvolle” gewesen, das zu bauen. Jedes hätte uns einen Tag gekostet. Und keines von ihnen hätte uns das beigebracht, was wir gelernt haben, indem wir das Produkt am zweiten Tag echten Nutzern präsentiert haben.

Die Lektion

Es gibt eine Version dieser Geschichte, in der wir zwei Wochen mit Architekturdiagrammen verbringen. In der wir Datenbankschemata in einem Google-Dokument diskutieren. In der wir eine ordentliche CI/CD-Pipeline einrichten, bevor wir irgendeinen Anwendungscode schreiben.

Diese Version der Geschichte endet mit einem schönen Plan und keinem Produkt.

Die Version, die tatsächlich passiert ist, endete mit einem funktionierenden Produkt und einer langen Liste von Dingen, die verbessert werden müssen. Wir würden diesen Tausch jedes Mal eingehen.

Achtundvierzig Stunden. Erster Commit bis zum Live-Produkt. Nicht, weil wir Genies sind. Sondern weil wir schnell Entscheidungen getroffen, schneller geliefert und Dinge in der Produktion behoben haben, wie es jeder tatsächlich tut — aber nur wenige zugeben.

Das Produkt, das du heute siehst, 84 Tage und 632 Commits später, begann genau dort. In 48 Stunden.