Produktambitionen eilen dem Datenmodell oft voraus. Die Schulden zeigen sich später, wenn jede neue Funktion Ausnahmen, Sync-Jobs, doppelten Zustand oder manuelle Bereinigung erfordert.

Ein SaaS-Team mit 50 Personen verbrachte kürzlich 12 Stunden pro Woche mit manuellem Reporting, weil es versucht hatte, ein altes Chat-Tool mit einem neuen Fintech-Angebot zusammenzuführen. Das Team dachte, das „Bündel“ würde die Kundenbindung steigern; stattdessen löste es über sechs Monate eine Spirale technischer Schulden aus. Die meisten Gründer sehen die „Super App“ als UI-Herausforderung, doch der eigentliche Friedhof ist Ihre Datenarchitektur.

Elon Musks X, Disney und Uber können es sich leisten, sich per „Vibe Coding“ durch massive Zusammenführungen von Diensten zu arbeiten, weil sie Tausende Engineers haben, die die Integration mit roher Gewalt durchsetzen. Für ein Startup mit 100 Personen ist es keine Evolution, „X Money“ in ein altes „X Chat“-Schema zu quetschen – es ist ein Selbstmordkommando für Ihre Reporting-Ebene. Wenn Ihre Kerntabellen nicht für Logik mit mehreren Entitäten gebaut wurden, geraten Ihre Produktambitionen ins Stocken, bevor das erste Update im App Store landet.

Die hohen Kosten, sich per „Vibe Coding“ zu einem Bündel vorzuarbeiten

Wenn Führungskräfte beschließen, Dienste zu bündeln – etwa wenn Airbnb Mietwagen hinzufügt oder OpenAI ChatGPT mit Browser-Werkzeugen verschmilzt –, übersehen sie oft die Realität der Infrastruktur. In einem aktuellen Projekt haben wir erlebt, wie ein mittelgroßes Unternehmen versuchte, eine zweite Produktlinie in seine Haupt-App zu integrieren. Weil das ursprüngliche Schema eine fest codierte user_id als Primärschlüssel für die gesamte Transaktionslogik verwendete, konnte es keine Nutzer abbilden, die in verschiedenen Diensten unterschiedliche Rollen hatten.

Das ist nicht nur eine Frage der Namenskonvention. Es ist ein grundlegendes Missverhältnis zwischen Geschäftslogik und Datengravitation. Wenn Sie ungleiche Dienste in einen Topf zwingen, verdoppelt sich die Komplexität Ihrer Abfragen nicht nur; sie wächst exponentiell. Am Ende haben Sie „God Tables“ mit über 100 Spalten, die sich nicht effizient indizieren lassen. Bevor Sie am Montagmorgen über ein Bündel entscheiden, müssen Sie sich bewusst machen, dass Code eine Verbindlichkeit ist und jede neue Funktion eine dauerhafte Steuer auf die Leistung Ihres Systems erhebt.

Warum westliche „Everything Apps“ meist auf Datenbankebene scheitern

WeChat und KakaoTalk waren erfolgreich, weil sie vom ersten Tag an als Ökosysteme gebaut wurden. Im Westen bauen wir stark fokussierte Apps mit nur einem Zweck wie Uber oder Twitter. Wenn diese Apps versuchen, sich zum „Super App“-Modell hin zu entwickeln, kämpfen sie gegen jahrelange Verkalkung des Schemas.

„Eine Tabelle mit 10 Mio. Zeilen, die für einfaches Messaging optimiert wurde, bricht in dem Moment zusammen, in dem Sie versuchen, sie mit einem hochfrequenten Hauptbuch für Finanztransaktionen zu joinen.“

Meta ist das Paradebeispiel für diesen Kampf. Das Unternehmen hat ein Jahrzehnt damit verbracht, Messenger und Fotos zu bündeln und wieder zu entbündeln, weil die Aufblähung der Nutzererfahrung oft ein direktes Spiegelbild des darunterliegenden Datenchaos ist. Wenn Ihre Entwickler mehr Zeit damit verbringen, „if-else“-Anweisungen für Sonderfälle zwischen gebündelten Diensten zu schreiben, als neue Funktionen auszuliefern, bauen Sie keine Super App – Sie bauen einen Monolithen, der zu schwer ist, um sich zu bewegen.

Technische Due Diligence: Was Sie vor dem Bündeln prüfen sollten

Bevor Sie sich auf eine Oberfläche für mehrere Dienste festlegen, müssen Sie Ihre Datensysteme nüchtern prüfen. Andernfalls werden Sie feststellen, dass 40 % der Tech-Stellen in die Wartung fließen statt in Innovation. Beginnen Sie mit diesen drei Prüfungen:

1. Identitätsauflösung: Kann Ihr System damit umgehen, dass ein einzelner Nutzer innerhalb des „Bündels“ unterschiedliche Berechtigungen, Abrechnungszyklen und Anforderungen an den Datenspeicherort hat? Wenn Ihre Tabelle users die einzige Quelle der Wahrheit ist, ist sie wahrscheinlich zu starr.
2. Event-Kollision: Wenn ein Nutzer in Ihrer App „klickt“, weiß Ihr Analytics-Schema, ob dieser Klick zum Dienst „Chat“ oder zum Dienst „Payments“ gehört? Ohne eine strikte Namensraum-Strategie wird Ihre Business Intelligence zum Spiegelkabinett.
3. Grenzen der Nebenläufigkeit: Wenn Ihr Dienst „Money“ ACID-Konformität erfordert, Ihr Dienst „Chat“ aber auf Eventual Consistency optimiert ist, zwingt Sie eine gemeinsame Datenbank zur Wahl zwischen Geschwindigkeit und Datenintegrität.

Die „Microsoft Office“-Falle: aufgeblähte UX als Datensymptom

Wenn Ihr Dienst anfängt, verschachtelte Menüs und komplexe Dropdowns zu benötigen, haben Sie im Grunde eine mobile Version von Microsoft Office geschaffen. Das passiert, weil das Produktteam versucht, jede neue Datenentität, die Sie dem Backend hinzugefügt haben, sichtbar zu machen. OpenAI musste kürzlich die Oberfläche von ChatGPT vereinfachen, weil der „Alles“-Ansatz das Werkzeug für durchschnittliche Verbraucher unbrauchbar machte.

Um das zu vermeiden, schauen Sie sich an, wie Netflix mit Komplexität umgeht. Netflix zeigt Ihnen nicht alles auf einmal, sondern nutzt dynamisch ausgelieferte, KI-gestützte Oberflächen, um die zugrunde liegende Komplexität zu verbergen. Das erfordert eine stark entkoppelte Datenebene, bei der die UI nicht die Struktur jeder Tabelle kennen muss, um einen aufgeräumten Startbildschirm darzustellen. Wenn Sie KI-Autopiloten und digitale Transformation nicht auf Architekturebene beherrschen, wird sich Ihre Super App einfach wie eine Krimskrams-Schublade anfühlen.

Wann Sie NICHT bündeln sollten: Plädoyer fürs Kleinbleiben

Bündeln ist eine Wachstumsstrategie, wird aber oft als Ablenkung von einem Kernprodukt genutzt, das auf einem Plateau angekommen ist. Wenn die Unit Economics von Dienst A nicht aufgehen, wird Dienst B in derselben App sie nicht auf magische Weise reparieren – er versteckt den Verlust nur in einer komplexeren GuV.

Für ein Startup mit 100 Personen kann der Aufwand für den Betrieb einer Super-App-Infrastruktur 30–50 % Ihrer gesamten Engineering-Kapazität verschlingen. Sofern der Datenaustausch zwischen den beiden Diensten den Nutzern kein zehnmal besseres Erlebnis bietet, sind Sie besser beraten, sie als getrennte, schlanke Einheiten zu führen. Pragmatisches Data Engineering bedeutet zu wissen, wann man Nein zu einer „einheitlichen“ Sicht sagt, die keinen echten geschäftlichen Mehrwert bietet.

Die wichtigsten Erkenntnisse

• Prüfen Sie Ihre Identitätsebene, bevor Sie Dienste zusammenführen; wenn Sie keine mandantenfähige Logik innerhalb eines einzelnen Nutzers abbilden können, scheitert das Bündel.
• Vermeiden Sie „God Tables“, indem Sie bei den Daten einen Microservice-Ansatz verfolgen, auch wenn die UI wie eine einzige App aussieht.
• Messen Sie die „Integrationssteuer“ in Entwicklerstunden; wenn die Synchronisierung von Diensten mehr als 20 % Ihres Sprints beansprucht, ist Ihr Schema der Engpass.
• Priorisieren Sie dynamische UIs, die Komplexität verbergen, statt jede neue Funktion auf dem Startbildschirm zu zeigen.

---

Häufig gestellte Fragen

Woran erkenne ich, ob mein aktuelles Schema für den Übergang zur Super App bereit ist?

Wenn Ihre wichtigsten Datenbanktabellen mehr als drei Joins benötigen, um eine einfache Frage zum Nutzerverhalten über verschiedene Funktionsbereiche hinweg zu beantworten, ist Ihr Schema wahrscheinlich zu starr. Prüfen Sie außerdem, ob Ihre zentralen Nutzer- und Transaktionstabellen fest codierte Abhängigkeiten von dienstspezifischer Logik enthalten.

Was sind die größten versteckten Kosten beim Bündeln getrennter Apps?

Die größten Kosten sind „Kontextschulden“: Entwickler müssen das gesamte vernetzte System verstehen, um eine einzige Funktion zu ändern. Das führt oft zu einem Rückgang der Deployment-Frequenz um 30 %, da die Testfläche über alle gebündelten Dienste hinweg wächst.

Sollten wir für alle Dienste einer Super App eine einzige Datenbank nutzen?

Fast nie. Auch wenn die UI einheitlich ist, sollte die Datenebene modular bleiben. Eine einzige Datenbank für ungleiche Dienste wie „Chat“ und „Payments“ schafft einen Single Point of Failure und zwingt Sie zu Kompromissen beim Performance-Tuning der Datenbank für unterschiedliche Workloads.

Eine Super App ist keine Designentscheidung, sondern eine architektonische Verpflichtung, die Ihr Geschäft entweder skaliert oder Ihr Engineering-Team unter unnötigen Schulden begräbt.

Nächster Schritt

Prüfen Sie, ob Ihr Schema die Produkt-Roadmap tragen kann. Sprechen Sie mit DataTip.