Database-First Fallstudie:Tabellen vor dem ersten Screen

In dieser Database-First Fallstudie habe ich die Datenbank entworfen, bevor ich einen einzigen Screen gebaut habe – und 18 Monate später, bei 1.000 Tabellen und weiterhin in Entwicklung, musste sie nie neu gebaut werden. Kein einziges Mal. Das ist die Fallstudie: was diese unglamourösen ersten Wochen gekostet haben und was sie genau gebracht haben.

Die Methode selbst – warum deine Daten vor deinen Screens kommen müssen – hat einen eigenen Beitrag: Database-First-Entwicklung. Dieser hier ist der Beweis. Einer Methode nickt man leicht zu, und man gibt sie leicht auf, sobald man ungeduldig etwas auf dem Bildschirm sehen will. Also hier, was tatsächlich passiert ist, als ich ein ganzes Produkt darauf gesetzt habe, zuerst den langweiligen Teil zu erledigen: FIKR Space, heute 11 integrierte Produkte und mehr als 3 Millionen Codezeilen, alle auf einem Datenfundament, das entworfen wurde, bevor irgendetwas davon existierte.

Database-First Fallstudie: zweieinhalb Wochen ohne etwas vorzuzeigen

Phase eins – eine Woche Domänen kartieren. Vor der ersten Codezeile habe ich jeden Bereich aufgelistet, den das System je berühren würde. Insgesamt mehr als 20 Domänen, die in fünf Gruppen fallen:

• Kern: Organisationen, Nutzer, Teams, Berechtigungen
• Produkt: Projekte, Aufgaben, Ziele, Sprints
• Geld: Cap Tables, Finanzierungsrunden, Transaktionen, Bewertungen
• Plattform: Accelerator-Programme, Bewerbungen, Kohorten, Lehrplan
• Support: Kommentare, Anhänge, Benachrichtigungen, Aktivitätsprotokolle

Phase zwei – eine Woche jede Tabelle entwerfen. Jede Tabelle bekam dasselbe Rückgrat: welche Organisation den Datensatz besitzt, wer ihn wann erstellt hat, wer ihn zuletzt wann geändert hat, und Löschungen, die Datensätze verbergen, statt sie zu zerstören. Auf diesem Rückgrat bekam jede Domäne ihre spezifischen Felder und ihre Listen von Status und Typen als editierbare Daten gespeichert – nie fest im Code verankert.

Phase drei – drei Tage Beziehungen kartieren. Eine vollständige Karte, wie alles zusammenhängt: welche Datensätze zu welchen gehören, welche viele-zu-viele verknüpft sind, welche – wie Kommentare und Anhänge – an alles angehängt werden können.

Insgesamt: etwa zweieinhalb Wochen. Das gesamte Fundament, entworfen und verknüpft – bevor ein Screen existierte. Für jeden Beobachter hatte ich nichts gebaut. Die Leute hielten mich für verrückt: „Warum fängst du nicht einfach an zu bauen und siehst unterwegs?“ Weil ich keine Zeit für einen Neubau hatte, kein Geld zu verschwenden und keinen Spielraum für Fehler. Die Datenbank musste beim ersten Mal stimmen.

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

Was das Database-First-Fundament tatsächlich gebracht hat

Dann begann die Auszahlung – und hörte nie auf. Hier ist jede größere Neugestaltung, die FIKR Space durchlaufen hat, und was jede von der Datenbank verlangte:

Fünf UI-Überarbeitungen. Null Datenbankänderungen. Die Screens sind Fenster in die Daten – ich konnte die Fenster endlos neu zuschneiden, weil sich die Wände nie bewegten. Diese Asymmetrie ist das ganze Argument für Database-First: Du kannst deine UI komplett neu gestalten; deine Datenbank kannst du nicht komplett neu gestalten.

Das Fundament brachte zwei weitere Dinge, die man mit Geld nicht nachrüsten kann. Erstens eine einzige Quelle der Wahrheit: Dashboard und Aufgabenliste können nie voneinander abweichen, weil jeder Screen dieselben Tabellen dieselben Fragen fragt. Zweitens Kundentrennung von Tag eins: Jeder Datensatz nennt die Organisation, der er gehört, sodass die Daten eines Kunden nie in das Konto eines anderen gelangen können – und jede Funktion, die ich seither hinzugefügt habe, erbte diesen Schutz automatisch.

Wie konnte ich überhaupt wissen, dass ich 1.000 Tabellen brauchen würde?

Konnte ich nicht. Ich kannte nicht jede Tabelle im Voraus – manche Domänen entwickelten sich weiter, und unterwegs kamen Felder hinzu. Aber ich kannte das System: eine mandantenfähige Plattform für Startups, Investoren und Accelerators, die echtes Geld verarbeitet, komplexe Berechtigungen und Audit-Trails braucht und bei der mehrere Produkte ein Fundament teilen. Das System zu kennen sagt dir, welche Arten von Tabellen existieren müssen – Entitäten, Beziehungen, Lookups, Audit-Logs –, noch bevor du jedes Feld kennst. Als neue Anforderungen auftauchten, passten sie in die bestehenden Muster, statt gegen sie anzukämpfen.

Das ist die Hälfte des Jobs, die dem Architekten gehört – die vollständige Rollenteilung steht in du bist der Architekt, die KI ist der Bauarbeiter. Die KI hat jede Migration genau so erzeugt, wie ich sie spezifiziert habe. Sie hat keine einzige Architekturentscheidung getroffen. Reine Ausführung. Und sie hat ständig gegen die Disziplin gekämpft: das Organisations-Tag vergessen, Indizes übersprungen, Abkürzungen vorgeschlagen – die Warnzeichen sind katalogisiert in 11 Anzeichen, dass die KI selbstbewusst falschliegt.

Das Gegenbeispiel: was Überspringen kostet

So sieht die UI-first-Version dieser Geschichte aus. Woche eins baust du ein hübsches Dashboard und legst eine Tabelle an, die es speist. Woche zwei baust du eine Aufgabenliste und legst eine weitere Tabelle an. Woche drei sagt das Dashboard 15 Aufgaben und die Aufgabenliste zeigt 18 – weil du jetzt zwei Quellen der Wahrheit hast und niemand weiß, wann sie auseinandergelaufen sind oder welche stimmt.

Jetzt skaliere das hoch. Angenommen, ich hätte die Kundentrennung übersprungen und müsste sie später ergänzen: jede Tabelle geändert, jede Abfrage neu geschrieben, jede Zugriffsregel erstellt, alle bestehenden Daten migriert. Wochen riskanter Arbeit, die alles auf einmal berührt – die Art Operation, die Solo-Produkte umbringt. Weil sie von Tag eins an eingeplant war, gab es nie etwas nachzurüsten.

Und das Geld? Die gesamte Tool-Rechnung für den Bau von all dem betrug 3.250 € – die Aufschlüsselung steht in dem 3.250-€-Stack. Der teure Input war nie Bargeld. Es war die Disziplin, zweieinhalb Wochen in Fundamente zu stecken, während es nichts zu demonstrieren gab. Hunderte Funktionen später, jede davon passgenau, bleibt das die renditestärkste Investition, die ich je in ein Produkt getätigt habe.

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

Häufig gestellte Fragen

Warum die gesamte Datenbank vor jeder UI entwerfen?

Weil sich die UI ändern kann und die Datenbank nicht – zumindest nicht günstig. Screens sind Fenster in die Daten; gestalte sie so oft um, wie du willst. Aber die Daten unter einem Live-Produkt umzustrukturieren heißt, jede Funktion auf einmal anzufassen. Bring das Fundament in Ordnung, und alles, was darauf gebaut ist, bleibt stehen.

Wie lange dauerte der Datenbankentwurf?

Etwa zweieinhalb Wochen: eine Woche, um mehr als 20 Domänen zu kartieren, eine Woche, um jede Tabelle mit gemeinsamem Rückgrat zu entwerfen, und drei Tage, um die Beziehungen dazwischen zu kartieren. Das ist der volle Preis des Fundaments – gemessen an 18 Monaten Bauen ohne Neubau.

Musste die Datenbank jemals neu gebaut werden?

Nein. Kein einziges Mal in 18 Monaten. Es kamen Felder hinzu und manche Domänen entwickelten sich weiter, aber immer innerhalb der bestehenden Muster. Fünf komplette UI-Neugestaltungen – Dashboard, Navigation, Layout, Styling, Mobile – erforderten zusammen null Datenbankänderungen.

Brauche ich 1.000 Tabellen für mein Produkt?

Nein. Diese Zahl spiegelt 11 integrierte Produkte wider, die ein Fundament teilen. Das Prinzip skaliert auf jede Größe herunter: Liste jede Entität in deinem System auf, kartiere, wie sie zusammenhängen, und entwirf alles, bevor du Screens baust. Die Disziplin ist dieselbe, ob dein Produkt ein Dutzend Tabellen braucht oder Hunderte.