Kurz vor dem Start kommt oft diese eine Frage, halb stolz, halb besorgt: "Und wenn das plötzlich alle nutzen, hält das dann?" Dahinter steckt ein Bild im Kopf: Die Software geht online, es läuft gut, und genau im besten Moment bricht alles zusammen. Reden wir ehrlich darüber, denn diese Angst führt oft zum teuersten Fehler, nicht zur besten Lösung.
Die Sorge ist verständlich. Du steckst Geld in etwas, das erfolgreich sein soll, und ausgerechnet der Erfolg könnte es umbringen. Nur: Die Antwort darauf ist fast nie "bau es gleich riesig". Sie ist "bau es so, dass es mitwachsen kann". Das ist ein Unterschied, der dich viel Geld sparen oder kosten kann, je nachdem, wem du zuhörst.
Zwei Ängste, die in verschiedene Richtungen ziehen
In der Frage stecken eigentlich zwei Sorgen, und sie widersprechen sich. Die eine: Was, wenn es funktioniert und der Ansturm das System in die Knie zwingt? Die andere, meistens von einem Verkäufer eingeredet: Du musst von Anfang an für Millionen bauen, sonst fängst du besser gar nicht erst an.
Die erste Sorge ist berechtigt und lösbar. Die zweite kostet dich Geld, bevor du den ersten Kunden hast. Und das Tückische daran: Wer der zweiten Angst nachgibt, baut sich die erste erst recht ein. Ein überladenes System hat mehr Stellen, an denen es kaputtgehen kann, als ein schlankes.
Der teuerste Fehler ist, zu früh für Grösse zu bauen
Für eine Million Nutzer zu bauen, die du nie bekommst, ist kein Vorsprung. Es ist Aufwand, den du bezahlst und nie brauchst. Jede Vorkehrung für gewaltige Last macht das System komplizierter, langsamer in der Entwicklung und teurer im Unterhalt. Du zahlst heute voll für ein Problem, das vielleicht in drei Jahren kommt. Vielleicht nie.
Dazu kommt das Unangenehme: Du weisst jetzt noch gar nicht, wo die Last später wirklich entsteht. Du baust also auf gut Glück Mauern an Stellen, an denen nie jemand drückt, während der echte Druck am Ende woanders kommt. Darum fangen wir lieber klein und sauber an, wie beim MVP in sechs Wochen, und ziehen die Kapazität dort hoch, wo wir sehen, dass sie gebraucht wird.
Das klingt nach Sparen am falschen Ort, ist aber das Gegenteil. Zu viel Technik auf Vorrat ist eine eigene Art von technischer Schuld. Sie steht im Weg, kostet bei jeder Änderung mit und zahlt sich nie zurück, wenn die Last ausbleibt.
"Skaliert nicht" heisst fast nie "zu viele Leute"
Wenn eine Software unter Last einbricht, liegt es selten an der blossen Zahl der Nutzer. Es liegt fast immer an einer einzelnen Stelle, die bei zehn Leuten niemand bemerkt und bei tausend das ganze System ausbremst. Ein Engpass, kein Wolkenbruch.
Ein typisches Beispiel: eine Übersichtsseite, die beim Öffnen jedes Mal die komplette Datenbank durchkämmt. Bei fünfzig Einträgen merkt das keiner. Bei fünfzigtausend lädt die Seite zehn Sekunden, und schon "skaliert die Software nicht". In Wahrheit skaliert eine einzige Abfrage nicht, und die lässt sich gezielt reparieren, ohne alles neu zu bauen.
Deshalb ist "hält das tausend Nutzer aus" die falsche Frage. Die richtige lautet: Wo sitzt der eine Engpass, der zuerst nachgibt, und wie teuer ist es, ihn zu weiten? Das kann man beantworten, statt pauschal Angst zu haben.
Gebaut, dass man anbaut. Nicht, dass man abreisst
Ob ein System mitwächst oder irgendwann abgerissen werden muss, entscheidet sich früh und unsichtbar. Sauber getrennte Teile, klare Schnittstellen und Ordnung im Code sind kein Selbstzweck. Sie sind genau das, was dir später erlaubt, eine überlastete Stelle zu verstärken oder auszutauschen, ohne den Rest anzufassen. Wachstum wird dann ein Anbau und kein Neubau.
Wann Skalierung wirklich ein Thema wird
Irgendwann kann der Punkt kommen, an dem es nicht mehr um eine einzelne Abfrage geht, sondern um echte Menge. Dann ist Skalierung real, und dann reden wir konkret darüber, statt vorher ins Blaue zu bauen.
Die gute Nachricht: Moderne Infrastruktur macht das meiste davon zu einer Frage von Einstellungen, nicht von Umbau. Leistung dazuschalten, wenn es eng wird, und zurückfahren, wenn der Andrang vorbei ist. Du zahlst für das, was du brauchst, dann wenn du es brauchst. Das ist planbar und um ein Vielfaches günstiger, als die grosse Maschine jahrelang leer mitlaufen zu lassen für den einen Tag, an dem sie sich lohnen würde.
Und falls dieser Tag kommt, der echte Ansturm, ist das kein Unfall, sondern meistens eine gute Nachricht. Dann ist dein Produkt gefragt, du hast Umsatz, und die Kapazität nachzuziehen ist ein Luxusproblem mit einer klaren Rechnung dahinter.
Software bricht unter Last selten dort, wo man Mauern gebaut hat. Sie bricht an der einen Stelle, an die keiner gedacht hat.
Die Faustregel
Bau für die Grösse, die du realistisch in einem Jahr erreichst, nicht für die, von der du träumst. Sorg dafür, dass die Teile sauber getrennt sind, damit du später jede einzelne für sich verstärken kannst. Dann ist Wachstum eine Frage von dazuschalten, nicht von abreissen und neu anfangen.
Die Frage ist also nicht, ob deine Software tausend oder eine Million Leute aushält. Die Frage ist, ob sie sauber genug gebaut ist, um mitzuwachsen, wenn es so weit ist. Für Grösse zu bauen, die nie kommt, ist verschwendetes Geld. So zu bauen, dass Grösse kein Neubau wird, ist einfach gute Arbeit. Das Zweite bekommst du bei uns, ohne dass du nach dem Ersten fragen musst.
Du willst eine Software, die mitwächst, ohne dass du heute für morgen überzahlst? Erzähl uns, was du vorhast, wir schätzen ehrlich ein, was dein Projekt wirklich braucht.
Jule
Co-Founder & Product · FlowCode Bern. Schreibt über das, was beim Bauen wirklich passiert.
