Database-First Entwicklung:Erst designen, dann prompten

Database-First Entwicklung bedeutet, deine Datenbank zu entwerfen, bevor du eine einzige Zeile Anwendungscode schreibst. Die zwei Wochen, die du in den Systementwurf steckst, bevor du baust, ersparen dir zwei Monate Refactoring während des Baus. Das ist keine Hypothese – es ist eine Rechenaufgabe, die sich in jeder Codebasis bewiesen hat, die ich je gesehen habe, auch in meiner eigenen.

Die wichtigsten zwei Wochen beim Bau von FIKR Space waren die zwei Wochen, in denen ich das Datenbankschema entworfen habe, bevor ich irgendeinen Anwendungscode schrieb. Die meisten nicken bei diesem Satz und ignorieren ihn dann. Das hier ist die praktische Version: die drei Dinge, die „die Architektur entwerfen“ tatsächlich bedeutet, und der Bau-Zeitplan, der darauf folgt.

Database-First Entwicklung: warum die Versuchung die Falle ist

Du wirst in Versuchung geraten, sobald du die Validierung abgeschlossen hast, Claude oder Cursor zu öffnen und loszubauen. Du willst den Dopamin-Kick wachsenden Codes. Du willst deinem Partner am Ende des Wochenendes einen Screenshot zeigen. Widerstehe.

Zu programmieren, bevor die Datenbank entworfen ist, ist der Hauptfehler – jede andere Bau-Falle folgt daraus. Am ersten Tag fühlst du dich produktiv, weil die KI Screens erzeugt, aber das Fundament darunter ist im Fluss, und jede Woche, in der sich das Fundament verschiebt, muss alles darauf Gebaute überarbeitet werden. Genau diese sich beschleunigende Überarbeitungsschleife ist es, mit der sich die Vibe-Coding-Falle um Menschen schließt, die sich in Woche eins unaufhaltsam fühlten.

Schritt 1: Die Datenbank entwerfen – auf Papier

Liste jede Entität in deinem Produkt auf. Nutzer. Unternehmen. Abonnements. Was auch immer die zentralen Substantive sind. Dann liste die Beziehungen auf: Ein Nutzer gehört zu einem Unternehmen, ein Unternehmen hat viele Nutzer, ein Abonnement gehört zu einem Unternehmen und erfasst die Nutzung.

Zeichne das auf Papier. Ja, Papier. Das Zeichnen zwingt dich, über Randfälle nachzudenken, die dir bei einem Entwurf nur im Kopf entgehen würden. Wenn sich Kästchen und Pfeile nicht mehr ändern, hast du ein Schema. Dann beschreibe die Entitäten Claude klar, und es schreibt dir das eigentliche SQL in zwanzig Minuten. Jetzt hast du dein Fundament.

Schritt 2: Die Service-Grenzen definieren

Welche großen Operationen führt dein System aus? Anmelden. Eine Zahlung verarbeiten. Einen Bericht erzeugen. Eine Benachrichtigung senden. Jede davon ist ein Service – ein in sich geschlossener Teil des Systems mit einer definierten Aufgabe. Definiere Ein- und Ausgaben jedes Services, bevor du den Service schreibst.

Das klingt bürokratisch. Ist es nicht. Es ist der Unterschied zwischen einem System, das sich weiterentwickeln kann, und einem, das nach drei Monaten verkalkt.

Schritt 3: Die User Flows durchgehen

Gehe die drei wichtigsten Dinge durch, die ein Nutzer mit deinem Produkt tun wird: sich anmelden, seine erste wertvolle Aktion abschließen, sein Abonnement verlängern. Skizziere jeden Flow als Abfolge von Screens oder Interaktionen – gestalte die Screens noch nicht, nur die Abfolge. Du suchst die Stellen, an denen der Flow bricht oder an denen du etwas angenommen hast, das nicht stimmen wird.

Wenn Datenbank, Services und Flows auf Papier alle Sinn ergeben – und immer noch Sinn ergeben, nachdem du sie einen Tag später mit frischen Augen betrachtet hast –, hast du eine Architektur. Jetzt kannst du bauen.

Das BuchThe Solopreneur RevolutionLuis Gonçalves darüber, wie du neben dem Job mit KI ein Solopreneur-Business aufbaust.Zum Buch →

Der Acht-Wochen-Zeitplan, der folgt

Architecture-first ist nicht langsamer. Es macht den schnellen Teil erst schnell. Das ist der Zeitplan, den es freischaltet, bei vier bis acht Stunden fokussiertem Bauen pro Woche:

Bis Ende Woche sechs laufen die drei oder vier Kern-Flows des Produkts: anmelden, die Hauptsache tun, abgerechnet werden, morgen wiederkommen und es erneut tun. Das kann eine Person 2026 leisten, was zehn Menschen 2020 für kein Geld der Welt konnten – und jede dieser wöchentlichen Funktionen beginnt mit einem schriftlichen Brief, nicht mit einem hoffnungsvollen Prompt. Das ist die PRP-Methode, und sie funktioniert nur, weil sich die Architektur darunter nicht mehr bewegt.

Lass die KI nicht den Architekten spielen

Claude ist ein brillanter Umsetzer und ein mittelmäßiger Architekt. Frag es „Soll das eine eigene Tabelle oder eine JSON-Spalte sein?“, und du bekommst eine Antwort – meist in Ordnung, manchmal schlecht, gelegentlich großartig. Das Problem: Du kannst nicht beurteilen, in welchem Fall du bist, wenn du keinen eigenen architektonischen Geschmack hast. Entwickle ihn bewusst: Sieh dir an, wie andere Produkte ihre Systeme strukturieren, arbeite die Abwägungen auf Papier durch und schreibe die Architektur auf, bevor du Claude bittest, sie umzusetzen.

Die Architekturentscheidungen sind deine. Die Umsetzungsentscheidungen sind Claudes. Halte diese Grenze, und die Codebasis gewinnt an Qualität; verwische sie, und die Codebasis verfällt.

Wenn du gerade an diesem Punkt stehst, hier deine Woche: Verbringe drei Abende mit Entitäten und Beziehungen. Zeichne das Schema auf Papier. Verfeinere es. Lass Claude das SQL erzeugen. Prüfe es auf Plausibilität, indem du deine drei wichtigsten User Flows durchgehst und schaust, ob das Schema sie sauber unterstützt. Schreibe noch keinen Anwendungscode. Bis Sonntagabend hast du ein Schema, dem du vertraust, und eine Liste der vier bis sechs Kernfunktionen, die du in den nächsten sechs Wochen baust. Langweilig. Langsam. Jede Stunde wert.

12 WochenDeine Konzernkarriere war nie der PlanBewirb dich beim Solopreneur Accelerator.Jetzt bewerben →

Häufig gestellte Fragen

Was ist Database-First Entwicklung?

Das Datenmodell zu bauen, bevor es Anwendungscode gibt: Liste die Entitäten und Beziehungen deines Produkts auf, verfeinere sie auf Papier, bis sie sich nicht mehr ändern, und erst dann erzeuge das Schema und beginne mit den Funktionen. Die Datenbank ist das Fundament – alles andere baut darauf auf, also muss sie zuerst aufhören, sich zu bewegen.

Wie lange sollte ich vor dem Programmieren in die Architektur investieren?

Zwei Wochen – Datenbank, Service-Grenzen und User Flows. Diese zwei Wochen sparen dir zwei Monate Refactoring während des Baus, weil Funktionen auf einem stabilen Fundament nicht jedes Mal überarbeitet werden müssen, wenn sich das Fundament verschiebt.

Kann die KI meine Datenbank für mich entwerfen?

Die KI kann das Schema schreiben – beschreibe deine Entitäten klar, und Claude erzeugt das SQL in zwanzig Minuten. Aber sie sollte die Entwurfsentscheidungen nicht treffen. Claude ist ein brillanter Umsetzer und ein mittelmäßiger Architekt: Die Entitäten, die Beziehungen und die Abwägungen sind deine Entscheidungen, bevor du promptest.

Ich bin nicht technisch – kann ich wirklich ein Schema entwerfen?

Ja, denn der schwierige Teil ist nicht technisch. Es geht darum, die Substantive deines Geschäfts aufzulisten – Nutzer, Unternehmen, Abonnements – und wie sie zusammenhängen, und das kennst du besser als jeder Entwickler. Kästchen und Pfeile auf Papier. Wenn sie sich nicht mehr ändern, ist der Entwurf fertig, und die KI übernimmt die Übersetzung in SQL.