Vom MVP zu 100.000 Nutzern: Was sich technisch ändern muss

Die meisten MVPs werden gebaut, um eine einzige Frage zu beantworten: Will das überhaupt jemand? Ein System mit 100.000 Nutzern beantwortet eine völlig andere: Überlebt das den Alltag, ohne dass das Team ausbrennt? Erstaunlich viele Startups scheitern nicht, weil das Produkt falsch war, sondern weil das System, das das Produkt einst bewiesen hat, am eigenen Erfolg zerbricht. In diesem Beitrag geht es darum, was sich technisch ändern muss, wenn man vom „funktioniert im Demo" zum „läuft jeden Tag für hunderttausend Menschen" übergeht – und genauso wichtig: was sich nicht ändern muss.

Das Wichtigste in Kürze

Der Kernfehler: Wachstum als lineares Problem behandeln

Gründer nehmen oft an, Skalierung sei additiv: Wir fügen einfach Server hinzu, wenn der Traffic wächst. Aber Wachstum ist nicht linear, und genau das ist die Falle. Bei 100.000 Nutzern ändern Lastmuster ihre Form, seltene Edge-Cases werden zu täglichen Ereignissen, Betriebskosten, die Rundungsfehler waren, tauchen als echtes Geld auf, und die menschlichen Prozesse – das manuelle Deployment, die eine Person, die weiß, wie die Datenbank aufgebaut ist – brechen, bevor es die Maschinen tun. Skalierung ist ein qualitativer, kein quantitativer Sprung: Das System tut nicht mehr vom Gleichen, es tut etwas anderes. Eine Query, die bei einer Häufigkeit von eins zu zehntausend in Ordnung ist, läuft im großen Maßstab ständig; ein Fehlermodus, der theoretisch war, wird zum Dienstag. Für „mehr vom Gleichen" zu planen ist der Grund, warum die Wand als Überraschung kommt.

Was gleich bleiben kann (zuerst die guten Nachrichten)

Fangen wir hier an, denn der Reflex, alles niederzureißen, ist der teurere Fehler. Du musst nicht alles neu schreiben, nicht reflexhaft Frameworks tauschen und nicht rückwirkend rechtfertigen, früh überengineert zu haben. Gute MVPs behalten ihre Kern-Domänenlogik, ihre wichtigsten Datenmodelle und ihre grundlegenden UX-Annahmen durch die Skalierung hindurch – und genau das ist der Punkt: Wenn diese unter Last brechen, war das Problem nie die Skalierung, sondern das Design. Das, was den Product-Market-Fit bewiesen hat, ist in der Regel erhaltenswert. Was sich ändert, ist alles drumherum – wie es betrieben, beobachtet, ausgeliefert und geschützt wird.

Was sich ändern muss (ohne Ausnahme)

1. Architektur: Von „es funktioniert" zu „es überlebt"

MVP-Architektur ist typischerweise synchron, eng gekoppelt und optimistisch – sie nimmt an, dass Dinge gelingen. Im großen Maßstab erzeugt dieser Optimismus kaskadierende Ausfälle (eine langsame Abhängigkeit reißt alles mit, was sie aufruft), Long-Tail-Latenz und Ausfälle, die schwer vorherzusagen sind. Was sich ändern muss, ist ein Wechsel vom „Happy Path" zu „so gebaut, dass es elegant scheitert": klare Systemgrenzen, asynchrone Verarbeitung für alles, was nicht auf dem kritischen Pfad liegt, idempotente APIs (damit ein Retry nicht doppelt abbucht oder doppelt verschickt) und explizite Fehlerbehandlung. Die Resilienz-Literatur – Michael Nygards Release It! ist die kanonische Quelle – benennt die Werkzeuge präzise: Circuit Breaker, die verhindern, dass eine ausfallende Abhängigkeit das ganze System mitnimmt, Bulkheads, die Fehler auf ein Abteil isolieren, Timeouts und Backpressure, damit eine langsame Komponente degradiert statt kollabiert. Unter all dem liegt eine Disziplin: zu entscheiden, was wirklich kritisch ist und was sicher ausfallen darf. Wenn alles kritisch ist, fällt alles aus – weil du nichts gebaut hast, das degradieren darf.

2. Datenzugriffsmuster (der stille Killer)

In der MVP-Phase funktionieren naive Queries, ORMs verbergen ihre eigene Ineffizienz, und die Daten sind klein genug, dass nichts davon zählt. Bei 100.000 Nutzern dominieren langsame Queries die Antwortzeit, N+1-Query-Probleme (das ORM feuert leise eine Query pro Zeile in einer Schleife) explodieren, und Background-Jobs stauen sich schneller, als sie abgearbeitet werden. Was sich ändern muss: Query-Disziplin (zu wissen, welches SQL dein ORM tatsächlich erzeugt), Lese-/Schreibtrennung (Read-Replicas, die die Leselast aufnehmen, damit Schreibvorgänge schnell bleiben), echte Hintergrundverarbeitung über eine Queue statt langsamer Arbeit im Request-Pfad und explizite Verantwortung für Performance, statt zu hoffen, dass das Framework das schon regelt. Hier sterben Systeme leise – nicht in einem dramatischen Crash, sondern indem die Antwortzeiten über ein Quartal von 200 ms auf zwei Sekunden kriechen, während alle „den Traffic" verantwortlich machen.

3. Observability: Von Logs zur Realität

Im MVP reichen Konsolen-Logs und einfaches Error-Tracking, weil du das ganze System im Kopf halten kannst. Im großen Maßstab werden Logs zu Rauschen, Probleme sind intermittierend, und Ausfälle sind systemisch statt lokal. Was sich ändern muss, ist der Übergang zu den drei Säulen der Observability – strukturierte Logs, Metriken und verteiltes Tracing – damit du einen einzelnen Request über Services hinweg verfolgen und tatsächlich sehen kannst, wo sich Zeit und Fehler ansammeln. Genauso wichtig ist, worauf du alarmierst: Reife Teams alarmieren auf Symptome (Nutzer erleben langsame Checkouts) statt auf Ursachen (die CPU ist bei 80 %) – das ist der SRE/SLO-Ansatz: Du weckst jemanden, wenn das Nutzerversprechen in Gefahr ist, nicht jedes Mal, wenn eine Metrik zuckt. Die nüchterne Version: Wenn du das System nicht sehen kannst, kannst du es nicht betreiben, und bei 100.000 Nutzern siehst du es nicht mehr, indem du Logs liest.

4. Deployment- und Release-Prozess

Manuelle Deployments überleben den Erfolg nicht. Im großen Maßstab braucht ein Team automatisiertes CI/CD, sichere Rollouts (Canary oder Blue-Green, damit ein schlechtes Release 1 % erreicht, bevor es 100 % erreicht), Rollbacks, die ohne Panik ablaufen, und Umgebungsparität, damit „funktioniert im Staging" etwas bedeutet. Der Grund ist ökonomisch: Jedes schlechte Deployment im großen Maßstab kostet direkt Nutzer, Vertrauen und Umsatz. Genau das misst die DORA-Forschung – Deployment-Frequenz, Lead Time, Change Failure Rate und Time to Restore Service – und ihre zentrale Erkenntnis ist es wert, hier wiederholt zu werden: Die Teams, die am häufigsten deployen, sind auch die stabilsten, weil sie Releases klein, automatisiert und umkehrbar gemacht haben. Deployment hört auf, eine lästige Pflicht zu sein, und wird zu einem geschäftskritischen System für sich.

Pro-Tipp: Die schnellste Einschätzung der Skalierungsreife eines Teams ist nicht das Architekturdiagramm – es ist die Antwort auf „Wie bringt ihr gerade jetzt einen Einzeiler-Fix in Produktion?" Wenn dazu ein Mensch, eine Checkliste und angehaltener Atem gehören, wird der Release-Prozess vor der Datenbank brechen.

5. Performance wird zum Feature

Im MVP tolerieren Nutzer etwas Langsamkeit, und Gründer gleichen den Rest manuell aus. Im großen Maßstab definiert Performance die Wahrnehmung, korreliert Churn mit Latenz, und Plattformen bestrafen Instabilität. Was sich ändern muss: explizite Performance-Budgets, Backend-Verantwortung für Latenz (weil der langsamste Teil meist eine Query oder eine API ist, nicht das Frontend) und kontinuierliches Monitoring gegen echte Nutzerdaten. Die zentrale Erkenntnis ist, dass Performance-Schulden schneller wachsen als Feature-Schulden – ein bisschen Latenz pro Release ist kaum spürbar, bis sich das Produkt kumulativ langsam anfühlt und niemand auf das Release zeigen kann, das es verursacht hat. (Warum ein sauberer Laborwert genau diesen Verfall im Feld verbergen kann, steht in warum Lighthouse-Scores lügen.)

6. Sicherheit und Compliance sind nicht mehr optional

Bei 100.000 Nutzern ziehst du Dinge an, die ein MVP nie angezogen hat: Missbrauch, Scraping, rechtliche Prüfung und Enterprise-Kunden, die ihre eigene Due Diligence durchführen. Was sich ändern muss: Rate Limiting, Audit-Trails, echte Berechtigungsmodelle und Datenschutzpraktiken, die standhalten – was für ein DACH- oder EU-Publikum bedeutet, dass die DSGVO eingebaut statt nachgerüstet wird. Sicherheit hört auf, ein „Später"-Punkt zu sein, und wird zur Wachstumsvoraussetzung: Der Enterprise-Deal, der deinen Umsatz verzehnfachen würde, ist auch der, dessen Einkaufsteam dich blockiert, wenn genau diese Kontrollen fehlen. Die Kosten, sie unter Deal-Druck nachzurüsten, sind weit höher, als sie einzubauen.

7. Teamstruktur muss zur Systemstruktur passen

Das ist die am meisten übersehene Veränderung von allen – und sie ist eigentlich keine technische. Wenn ein Team alles besitzt, Verantwortlichkeiten unscharf sind und Wissen Stammeswissen ist, wird das System zum Flaschenhals – nicht, weil der Code schlecht ist, sondern weil jede Änderung über dieselben überlasteten Menschen laufen muss. Das ist Conway's Law: Organisationen liefern Systeme aus, die ihre Kommunikationsstruktur spiegeln, ob sie es beabsichtigen oder nicht. Im großen Maßstab muss Verantwortung explizit werden, müssen Schnittstellen zwischen Bereichen dokumentiert werden, und müssen sich Teams an Systemgrenzen ausrichten. Der raffinierte Zug ist das Inverse-Conway-Manöver – die Teams bewusst so zu formen, dass sie die gewünschte Architektur erzeugen, statt ein zufälliges Organigramm eine zufällige Architektur aufzwingen zu lassen. So oder so: Du kannst dich nicht aus Conway's Law ausklinken; du kannst nur wählen, ob es für oder gegen dich arbeitet.

Die Rewrite-Falle (und wie man sie vermeidet)

Viele Startups erreichen 100.000 Nutzer und schließen daraus: Wir müssen alles neu schreiben. Meist ist das falsch, und es ist der gefährlichste Reflex in dieser Phase. Was tatsächlich gebraucht wird, ist fast immer architektonisches Refactoring, Trennung der Zuständigkeiten und operative Reife – kein Neubau von Grund auf. Rewrites frieren die Feature-Entwicklung ein, setzen mühsam erworbenes Lernen zurück und monopolisieren über Monate die Aufmerksamkeit der Führung, während die Konkurrenz weiter ausliefert. Refactoring bewahrt das Momentum; ein Rewrite verbraucht es. Die kanonische Technik, um von einem verworrenen MVP zu einem skalierbaren System zu kommen, ohne einen Big-Bang-Rewrite, ist das Strangler-Fig-Pattern (von Martin Fowler nach der Würgefeige benannt, die um einen Baum wächst und ihn allmählich ersetzt): Du baust die neuen, sauber abgegrenzten Teile neben den alten, leitest den Traffic schrittweise dorthin um und ziehst den alten Code Stück für Stück zurück – während du die ganze Zeit live und auslieferbar bleibst. Es klingt langsamer als „schreib's einfach neu" und ist in der Praxis dramatisch schneller, weil du nie stehen bleibst. (Das tiefere Argument, warum der Rewrite-Reflex meist ein Symptom statt einer Lösung ist, steht in warum Geschwindigkeit ohne Architektur eine Falle ist.)

Die Denkweise des Technical Co-Founders

Die besten Skalierungsteams stellen wiederholt eine bestimmte Reihe von Fragen: Was bricht unter Last? Was scheitert leise? Was darf sicher degradieren? Was darf nie ausfallen? Beachte, dass es hier um Fehler geht, nicht um Features – denn im großen Maßstab ist das elegante Managen von Fehlern das Feature. Sie bauen Systeme, die sich biegen, nicht brechen: die Last abwerfen, ein nicht-essenzielles Feature degradieren und das Kernversprechen intakt halten, wenn etwas schiefgeht, statt ein Binär aus „perfekt" oder „aus" zu präsentieren. Diese Denkweise – anzunehmen, dass Dinge scheitern werden, und dafür zu konstruieren – ist der Unterschied zwischen einem System, das einen schlechten Nachmittag hat, und einem, das ein schlechtes Quartal hat.

Pro-Tipp: Stell die Frage „Was darf nie ausfallen?" deinem ganzen Team und beobachte, wie unterschiedlich die Antworten sind. Wenn Vertrieb, Support und Engineering jeweils ein anderes „Kernversprechen" nennen, hast du die eigentliche Skalierungsarbeit gefunden – nicht im Code, sondern im fehlenden Konsens darüber, wofür das System eigentlich da ist.

Der H-Studio-Ansatz: Engineering für die zweite Phase

Wir werden oft genau an dem Wendepunkt hinzugezogen, um den es in diesem Beitrag geht: Das MVP hat funktioniert, und jetzt tut alles weh. Die Arbeit besteht darin, die Architektur zu stabilisieren, die verborgenen Flaschenhälse zu beseitigen (fast immer zuerst im Datenzugriff und im Release-Prozess) und das System auf echtes Wachstum vorzubereiten – entscheidend: ohne das Produkt-Momentum zu stoppen, denn ein Startup, das für einen dreimonatigen Neubau im Dunkeln verschwindet, kommt oft nicht zurück. Der Strangler-Fig-Ansatz „refactor, don't rewrite" existiert genau deshalb, damit du das Fundament reparieren kannst, während du noch im Haus wohnst.

Schlussgedanke

Bei Skalierung geht es eigentlich nicht darum, mehr Nutzer zu bewältigen. Es geht darum, mehr Realität zu bewältigen – mehr Variabilität, mehr Fehler, mehr Erwartungen, mehr Edge-Cases, die früher selten waren und jetzt konstant sind. Die Zahl 100.000 ist willkürlich; was zählt, ist, ob dein System die Unordnung, die Volumen mit sich bringt, absorbieren kann, ohne das Team beim Warten auszubrennen. Bau ein System, das Realität bewältigt, und 100.000 Nutzer sind nur eine Zahl, an der du auf dem Weg zur nächsten vorbeikommst.

— Anna

Hol dir ein Scale-Readiness-Review mit H-Studio

Wenn dein MVP funktioniert, du dich aber 100.000 Nutzern näherst, überleben die Systeme, die dich hierher gebracht haben, vielleicht nicht die nächste Phase – und der günstigste Moment, das zu beheben, ist, bevor die Verlangsamung offensichtlich ist, nicht danach. Wir helfen Startups, vom MVP zum Wachstum zu skalieren, indem wir die Architektur stabilisieren und verborgene Flaschenhälse beseitigen, ohne das Produkt-Momentum zu stoppen, und unsere Backend-Entwicklung behebt die Datenzugriffsmuster, asynchrone Verarbeitung und Performance-Verantwortung, die zuerst scheitern. Sieh dir alle unsere Engineering-Services an oder nimm Kontakt auf – wir prüfen unter Druck, ob dein System die Realität absorbieren kann, die 100.000 Nutzer mit sich bringen.

FAQ

Müssen wir unser MVP neu schreiben, um zu skalieren?

Fast nie. Gebraucht werden meist Refactoring, Trennung der Zuständigkeiten und operative Reife – kein Rewrite. Das Strangler-Fig-Pattern erlaubt es, Teile inkrementell zu ersetzen, während das System live bleibt, und bewahrt so das Momentum, das ein Rewrite zerstören würde.

Was bricht zuerst, wenn ein MVP skaliert?

Am häufigsten der Datenzugriff (langsame Queries, N+1-Probleme, fehlende Lese-/Schreibtrennung) und der Release-Prozess (manuelle Deployments, die nicht mithalten). Lücken in der Observability machen dann beides schwer zu diagnostizieren. Diese drei scheitern meist vor der Produktlogik.

Was können wir sicher aus dem MVP behalten?

Typischerweise die Kern-Domänenlogik, die wichtigsten Datenmodelle und die Kern-UX. Wenn die wirklich nicht skalieren können, ist das ein Design-Problem, kein Skalierungsproblem. Bewahre, was den Product-Market-Fit bewiesen hat, und ändere das Drumherum.

Warum ist Teamstruktur ein technisches Skalierungsthema?

Wegen Conway's Law – dein System spiegelt am Ende deine Kommunikationsstruktur. Unscharfe Verantwortung und Stammeswissen blockieren die Lieferung unabhängig von der Codequalität. Im großen Maßstab brauchst du explizite Verantwortung und Teamgrenzen, die zu den Systemgrenzen passen.

Woran erkennen wir, dass wir am Wendepunkt sind?

Die Anzeichen: Antwortzeiten, die von Release zu Release kriechen, „lass uns den Teil nicht anfassen" im Vokabular des Teams, Incidents, die intermittierend und schwer reproduzierbar sind, und Deployments, die sich riskant anfühlen. Keines ist ein Crash – es wird einfach schwerer, sich zu bewegen, und genau das ist die Warnung, an deren Ende die Rewrite-Falle wartet.