Die meisten digitalen Produkte brauchen irgendwann drei Dinge: eine Mobile-App, eine Web-App und ein Backend, das beide versorgt. Der klassische Weg dorthin sind drei Technologien, drei Codebasen und faktisch drei Teams, wobei jede Funktion zweimal umgesetzt und jede Änderung über alles hinweg abgestimmt wird. Wir bauen alle drei in einer Sprache. Dieser Beitrag erklärt, was das konkret heißt und warum es keine Entwicklervorliebe ist, sondern direkt Ihr Budget, Ihren Zeitplan und die Frage betrifft, wie sicher sich Ihr Produkt weiterentwickeln lässt.
Der Stack in einem Absatz
Web-App in Next.js. Mobile-App in React Native. Backend in Nest.js. Alle drei in TypeScript, eine Sprache von Anfang bis Ende. Sie leben in einem Repository (einem „Monorepo“), dazwischen liegen geteilte Pakete: eines für Typen (die Definitionen Ihrer Daten), eines für Geschäftslogik (die Regeln Ihres Produkts), eines für Hilfsfunktionen. Web-App, Mobile-App und Server importieren aus derselben geteilten Quelle, statt eigene Kopien zu pflegen.
Was „geteilte Typen“ tatsächlich verhindern
Hier die alltägliche Katastrophe in Drei-Technologien-Projekten: Das Backend-Team benennt ein Feld um, sagen wir „price“ wird zu „priceInCents“. Das Web-Team aktualisiert seine Kopie. Das Mobile-Team bekommt die Nachricht nicht. Die Mobile-App zeigt jetzt jedes Produkt hundertmal günstiger, und niemand merkt es, bis es ein Kunde merkt. Diese Fehlerklasse existiert, weil jede Codebasis ihre eigene private Beschreibung derselben Daten pflegt und diese Beschreibungen still auseinanderdriften.
Mit geteilten Typen gibt es genau eine Beschreibung davon, wie ein „Produkt“, eine „Bestellung“ oder ein „Nutzer“ aussieht, und alle drei Apps importieren sie. Ändert das Backend ein Feld, lassen sich Web- und Mobile-Code, die davon abhängen, sofort nicht mehr kompilieren, auf dem Rechner des Entwicklers, mit einer präzisen Liste jeder betroffenen Stelle. Der Widerspruch wird in Minuten am Schreibtisch gefunden, nicht in der Produktion von Ihren Kunden.
“Geteilte Typen machen aus „die App ist kaputt, weil sich der Server geändert hat“ statt eines Produktionsvorfalls eine rote Unterstreichung im Editor.”
Geteilte Logik: Ihre Geschäftsregeln, einmal geschrieben
Typen sind das Fundament; wertvoll wird es bei geteilter Logik. Nehmen Sie etwas Alltägliches: wie eine Bestellsumme berechnet wird, Positionen, Rabattregeln, Liefergebühr, Mehrwertsteuer. Im klassischen Aufbau wird diese Logik dreimal geschrieben, und früher oder später sagt das Web 47,90 € und die App 48,20 €, und jemand verbringt einen Tag mit der Ursachensuche. Bei uns ist es eine Funktion im geteilten Paket, die Web, Mobile und Server nutzen. Sie kann sich nicht selbst widersprechen. Dasselbe gilt für Validierungsregeln („was zählt als gültige Buchung?“), Formatierung und Berechtigungen.
Was das für Budget und Zeitplan bedeutet
- Ein Team statt drei: dieselben Entwickler arbeiten an Web, Mobile und Backend, kein Abstimmungsaufwand, kein „wir warten auf das Backend-Team“
- Funktionen kosten weniger: die Logikschicht wird einmal geschrieben; nur die Oberflächen entstehen je Plattform
- Änderungen sind sicherer: der Compiler findet automatisch jede Stelle, die eine Änderung berührt, über alle drei Apps hinweg
- Einarbeitung geht schneller: ein neuer Entwickler lernt eine Sprache und ein Repository, nicht drei Ökosysteme
- Mit einer Plattform zu starten bleibt günstig: erst mobil launchen, und wenn die Web-App später kommt, erbt sie Typen und Logik ab dem ersten Tag
Die ehrlichen Grenzen
Wird also alles geteilt? Nein, und das wäre auch nicht wünschenswert. Die Oberflächen selbst entstehen getrennt, denn eine gute mobile und eine gute Web-Oberfläche unterscheiden sich wirklich: andere Navigation, andere Gesten, andere Layouts. Geteilt wird alles unter der Oberfläche: die Datendefinitionen, die Regeln, die Berechnungen. In der Praxis sind das typischerweise 30–50 % des gesamten Codes, und genau der Teil, in dem Fehler am teuersten sind. Wir teilen das Fundament, nicht die Tapete.
Warum das auch nichttechnische Gründer angeht
Sie werden vielleicht nie in den Code schauen, aber Sie spüren diese Architektur auf drei Wegen: Ihre Angebote sind niedriger, weil Funktionen nicht zweimal gebaut werden; Ihr Produkt geht schneller live, weil ein Team ohne Übergaben arbeitet; und zwei Jahre später haben Sie immer noch ein zusammenhängendes System statt dreier auseinandergelaufener, was genau das ist, worauf ein technischer Mitgründer, die Due Diligence eines Investors oder ein Käufer schaut. Wenn Sie ein Produkt planen, das eines Tages auf Web und Mobile lebt, ist das eine der wirkungsvollsten Entscheidungen, die Sie treffen, noch bevor der erste Screen entworfen ist. Wir zeigen Ihnen gern, wie das bei Ihrem konkreten Produkt aussähe, ohne Fachjargon, versprochen.
