In jedem App-Projekt taucht irgendwann diese Frage auf: „Brauchen wir dafür ein Backend?“ Sie klingt technisch, ist aber im Kern eine Budget- und Zeitfrage, denn die Antwort kann Ihre MVP-Kosten um mehrere tausend Euro verschieben. Hier die Klartext-Fassung, die wir mit Gründern durchgehen, samt der Fälle, in denen die ehrliche Antwort „noch nicht“ lautet.
Zuerst: Was ist ein Backend, menschlich erklärt?
Die App auf dem Handy ist der Teil, den Nutzer sehen. Das Backend ist alles dahinter: wo die Daten liegen, wo die Regeln laufen („hat dieser Nutzer bezahlt?“, „wer darf das sehen?“) und wo Konten verwaltet werden. Jede ernsthafte App hat irgendwo eines, die eigentliche Frage ist, ob es ein fertiger Dienst ist, den man konfiguriert, oder ein System, das für Ihr Produkt gebaut wurde.
Option 1: Backend as a Service (Firebase, Supabase und Co.)
Dienste wie Firebase oder Supabase liefern ein vorgefertigtes Backend: Nutzerkonten, Datenbank, Dateispeicher, Benachrichtigungen, konfiguriert statt programmiert. Für viele MVPs ist das wirklich die richtige Wahl, und eine Agentur, die in jedem Projekt ein eigenes Backend durchdrückt, optimiert ihre Rechnung, nicht Ihre Runway.
- Ihre App speichert und zeigt vor allem Daten: Notizen, Gewohnheiten, Trainings, gemerkte Einträge, einfache Profile
- Die Regeln sind einfach: Nutzer sehen ihre eigenen Daten, teilen davon vielleicht etwas
- Sie müssen die Idee validieren, bevor Sie in Infrastruktur investieren
- Ersparnis: typischerweise 3.000–8.000 € gegenüber einem eigenen Backend und 1–2 Wochen Zeit
Option 2: Ein eigenes Backend
Ein eigenes Backend (wir bauen unsere in Nest.js, warum, dazu gleich mehr) bedeutet, dass die serverseitige Logik eigens für Ihr Produkt geschrieben wird. Es kostet anfangs mehr und existiert aus einem Grund: Manche Produkte lassen sich schlicht nicht als Konfiguration ausdrücken.
- Komplexe Geschäftslogik: Fahrer und Fahrgäste zusammenbringen, dynamische Preise berechnen, mehrstufige Freigaben
- Geld jenseits eines einfachen Checkouts: Abos, Auszahlungen an Nutzer, Provisionen, Rechnungsstellung
- Integrationen mit anderen Systemen: Lager, CRM, Zahlungsanbieter, Behörden-APIs
- Mehrere Nutzerrollen mit wirklich unterschiedlichen Rechten und Abläufen
- Daten, die Sie vollständig besitzen und kontrollieren müssen, häufig in Gesundheit, Finanzen und B2B-Verträgen
- Eine Web-App, die neben der Mobile-App geplant ist und dieselben Daten und Logik teilt
Die Anzeichen, dass Sie Firebase überwachsen haben
Viele erfolgreiche Apps starten auf Firebase und migrieren später, das ist kein Scheitern, das ist der Plan, der aufgeht. Die Anzeichen: Ihre Datei mit „Sicherheitsregeln“ ist zu einem unlesbaren Roman geworden; Sie schreiben immer mehr Cloud Functions, um fehlende Logik zu umgehen; Abfragen, die sofort waren, werden langsam oder teuer; oder ein Geschäftspartner fragt, wo genau die Daten liegen, und Sie brauchen eine bessere Antwort. Eine Migration ist ein normales, planbares Projekt und kein Neuschreiben Ihrer App.
“Firebase für Ihr MVP zu wählen ist kein Sparen an der falschen Stelle. Ein eigenes Backend zu bezahlen, bevor Sie Nutzer haben, das kürzt Ihre Runway.”
Warum wir eigene Backends in Nest.js bauen
Wenn ein Projekt wirklich ein eigenes Backend braucht, bauen wir es in Nest.js, einem ausgereiften, klar strukturierten Framework in TypeScript, also derselben Sprache wie unsere Web- (Next.js) und Mobile-Apps (React Native). Eine Sprache über das ganze Produkt bedeutet, dass dasselbe Team an allem arbeitet, Datendefinitionen geteilt statt dupliziert werden und eine ganze Fehlerklasse nach dem Muster „die App erwartete X, der Server schickte Y“ verschwindet. Für Sie heißt das: weniger Leute nötig, schnellere Änderungen und ein Team, das für das gesamte System verantwortlich ist.
Der ehrliche Entscheidungsweg
- Beschreiben Sie den Kern Ihrer App in einem Satz. Lautet er „Nutzer speichern und sehen X“, starten Sie mit Firebase/Supabase.
- Enthält der Satz „vermittelt“, „berechnet“, „zahlt aus“, „genehmigt“ oder „integriert sich mit“, planen Sie ab Tag eins ein eigenes Backend ein.
- Wenn Sie unsicher sind, starten Sie mit einem verwalteten Dienst und planen Sie die Migration als Meilenstein, nicht als Notfall.
- Überlassen Sie diese Entscheidung nie dem, der an der Antwort verdient. Verlangen Sie eine Begründung in Klartext, so wie in diesem Beitrag.
Sie haben Ihre App in einem Satz beschrieben und wissen trotzdem nicht, auf welcher Seite Sie stehen? Schicken Sie uns diesen Satz. Wir sagen Ihnen, welches Setup passt, was es kostet, und wenn die Antwort „Firebase reicht völlig“ lautet, sagen wir genau das.
