Viele junge Startups beginnen ihre Reise mit einem sogenannten MVP, einem Minimum Viable Product. Diese erste Version des Produkts wird meistens unter hohem Zeitdruck und ohne großen Anspruch an Perfektion entwickelt. Sinn und Zweck ist es, möglichst schnell herauszufinden, ob das Geschäftsmodell grundsätzlich funktioniert und auf Resonanz stößt. Funktioniert es nämlich nicht, hat man keine allzu großen Ressourcen verschwendet und kann die Idee zugunsten anderer Ansätze fallenlassen. So entsteht das MVP oft eher „zusammengeschustert“ als makellos programmiert. Der Fokus liegt auf der schnellen Validierung beim Kunden statt auf sauberem Code und durchdachter Architektur. Das ist in der Frühphase völlig legitim und Bestandteil vieler Lean-Startup-Methoden. Je schneller man Feedback bekommt, desto eher kann man Hypothesen verwerfen oder bestätigen. Manchmal ist das Ergebnis chaotisch, aber wenn die Resonanz stimmt und Nutzerinnen und Nutzer einen echten Mehrwert erkennen, können die nächsten Schritte folgen. Doch sobald das Produkt zu wachsen beginnt, werden auch die Anforderungen an Stabilität, Sicherheit und Skalierbarkeit größer. Das vormals pragmatisch konzipierte MVP kann sich rasch als Dauer-Baustelle entpuppen: Neue Funktionen lassen sich nur mühsam integrieren, Performance-Probleme treten verstärkt auf und die Wartung wird immer komplizierter. Viele Startups gelangen an den Punkt, wo sie sich fragen, ob es sich überhaupt lohnt, noch weiter in den alten Code zu investieren – oder ob ein kompletter Neustart auf Basis der gesammelten Erkenntnisse sinnvoller wäre.
1. Wann lohnt sich ein kompletter Neubeginn?
Die Entscheidung für einen Rewrite, also das Wegwerfen des MVPs und den Neubau auf grüner Wiese, ist nicht trivial. Dennoch gibt es Situationen, in denen dieser radikale Schritt sinnvoll sein kann. Ein häufiges Beispiel sind extreme Architekturprobleme. Was für ein kleines MVP noch ausreichend war, kann bei stetig steigenden Nutzerzahlen und höheren Anforderungen förmlich in sich zusammenfallen. Das System verliert immer mehr an Stabilität, und die Teams versuchen nur noch, Löcher zu stopfen. Spätestens wenn selbst kleine Features ewig dauern und kein Ende der Flickschusterei in Sicht ist, ist der Zeitpunkt gekommen, über einen umfassenden Neustart nachzudenken. Ein weiterer Auslöser ist ein sogenannter Pivot, also die Neuausrichtung des Geschäftsmodells. Wenn die Erkenntnisse aus der MVP-Phase zeigen, dass der eigentliche Markt woanders liegt oder sich die Zielgruppe völlig anders verhält als erwartet, kann es sein, dass das alte System gar nicht mehr passt. Hier kann ein Neubeginn von Vorteil sein, weil man für das neue Produkt ohnehin eine andere technische Basis braucht. Auch bei hohen Sicherheits- oder Performanceanforderungen wird ein MVP schnell an seine Grenzen stoßen, gerade wenn es ursprünglich nur dafür gedacht war, grobe Hypothesen zu testen. In stark regulierten Branchen, etwa im Gesundheitswesen oder im Zahlungsverkehr, muss man an bestimmten technischen Standards und rechtlichen Vorgaben festhalten, die sich nur schwer in eine zusammengeflickte MVP-Struktur integrieren lassen. Ein gründlicher Neustart ist dann oft weniger aufwendig als ein Dauer-Refactoring. Gleichzeitig birgt ein Rewrite immer Risiken. Wer neu beginnt, investiert viel Zeit und Geld, während das alte System weiter betrieben werden muss. Man setzt die Teams einer Doppelbelastung aus: Einerseits halten sie den bisherigen Betrieb am Laufen, andererseits arbeiten sie am neuen Produkt. Es kann außerdem passieren, dass man viel implizites Wissen über Bord wirft. Zahlreiche Fehler und Workarounds sind in der alten Codebasis bereits erkannt oder behoben worden; beim Neubau könnte man unwissentlich wieder dieselben Fehler machen.
2. Zwischen Pragmatismus und Zukunftsfähigkeit
Die Frage nach einem Neubeginn ist letztlich eine strategische Entscheidung. Einerseits kann man ein MVP schrittweise modernisieren, indem man Module austauscht oder es Stück für Stück refaktoriert. Das ist häufig der pragmatischste Weg, weil man so nicht von null anfängt und parallel weiterarbeiten kann. Dieser iterative Ansatz – manchmal als Strangler Fig Pattern bekannt – sieht vor, alte Funktionalitäten langsam durch neue zu ersetzen. So verteilt man das Risiko und kann früher Feedback bekommen, ob der neue Code tatsächlich hält, was er verspricht. Andererseits kann ein radikaler Schnitt langfristig wertvoll sein, wenn die Codebasis wirklich unhaltbar ist oder ein kompletter Strategiewechsel ansteht. Dann kann man beim Neubau eine saubere Architektur wählen, Technologie-Entscheidungen klug treffen und ein Setting aufsetzen, das verlässlicher skaliert. Wichtige Best Practices – etwa Test-Driven Development, automatisiertes Deployen oder klare Dokumentation – lassen sich von Anfang an verankern. Das spart langfristig Zeit, Nerven und damit Geld. Egal ob man sich für den radikalen Neustart oder den Weg der kontinuierlichen Verbesserung entscheidet: Ausschlaggebend sind immer die aktuellen Unternehmensziele und die Ressourcen, die zur Verfügung stehen. Ein Startup sollte sich die Fragen stellen, wie schnell es wachsen muss, wie empfindlich die bisherigen Kunden auf Störungen reagieren und wo die größten Chancen und Risiken liegen. Ein Rewrite kann ein starkes Signal sein, dass man bereit ist, die nächsten Level zu erklimmen – vorausgesetzt, man geht ihn durchdacht an und lernt konsequent aus den Erfahrungen des MVPs.
3. Lohnt sich der Wegwurf? Eine Kosten-Nutzen-Analyse
Die zentrale Frage, die sich viele Gründerinnen und Gründer stellen, lautet: „Ab wann rechnet es sich überhaupt, den MVP wegzuwerfen?“ Eine einfache Formel dafür gibt es nicht, dennoch kann man eine grobe Kosten-Nutzen-Analyse durchführen, um eine fundierte Entscheidung zu treffen. Auf der Kostenseite schlägt zunächst die Entwicklungszeit für den Rewrite zu Buche. Ein komplettes Neubauprojekt bindet in der Regel mehrere Monate lang ein nennenswertes Team von Entwicklerinnen und Entwicklern. In dieser Phase können weniger neue Features für das bestehende System erstellt werden, und die Kundenwartung muss parallel gesichert sein. Dadurch entstehen Opportunitätskosten, weil man womöglich neue Marktchancen verpasst oder länger braucht, um auf Kundenwünsche zu reagieren. Dem gegenüber stehen jedoch die sogenannten „technical debts“, also die technischen Schulden des alten MVPs. Diese äußern sich in permanenten Bugfixes, Performance-Einbrüchen, schlecht durchdachten Workarounds und hoher Komplexität im Code. Man kann versuchen, den Entwicklungsaufwand für kommende Features und notwendige Wartung in Euro oder Personenstunden pro Monat zu beziffern und beobachten, ob dieser Wert stetig steigt. Wenn sich die Entwicklungskosten auf Dauer exponentiell erhöhen, kann ein radikaler Schnitt günstiger sein als ein ewiges Herumdoktern. Auch die Produktivität des Teams spielt eine Rolle. Wenn immer mehr Zeit mit Fehlersuche, Flickschusterei und komplizierten Deployments verplempert wird, sinkt die Effektivität. In solchen Situationen kann ein sauberer Neustart die Moral und Leistungsfähigkeit des Teams steigern und langfristig die Projektkultur verbessern. Gerade in einem Startup ist Geschwindigkeit ein entscheidender Wettbewerbsfaktor – wenn das alte System diese bremst, kostet es nicht nur Geld, sondern auch Marktchancen. Außerdem sollte man die strategische Ausrichtung berücksichtigen: Handelt es sich um eine Software, die in Zukunft sehr großen Nutzerzuwachs erwarten lässt? Müssen hohe Compliance-Anforderungen erfüllt werden, was wiederum robustere Architekturen verlangt? Oder bleibt das Produkt eher nischig, sodass ein Iterieren am alten System genügt? Je größer die Wachstumserwartungen und je höher die Anforderungen, desto eher wird sich ein Neubeginn auszahlen. Am Ende kann man nur auf Basis einer realistischen Hochrechnung entscheiden. Versucht, die kurzfristigen Aufwände für einen Neubau – personell und finanziell – abzuwägen gegen die langfristigen Vorteile eines modernen, skalierbaren Systems. Berücksichtigt dabei auch, wie viel Wissen ihr aus dem MVP ziehen könnt und wie gut ihr diese Erkenntnisse in den Neubau integriert. Gibt es zudem einen klaren Plan, ab welchem Feature-Set ihr das neue Produkt launchen könnt, und wie vermeidet ihr im Entwicklungsprozess unnötige Verzögerungen? Wenn sich abzeichnet, dass die Kosten für den Weiterbetrieb und die Wartung des alten MVPs in den kommenden Monaten höher liegen werden als die einmalige Investition in ein sauberes Rewrite, ist der Wegwurf möglicherweise die richtige Entscheidung. Letztlich zeigt sich, dass es auf eine saubere Gegenüberstellung von Aufwand und Nutzen hinausläuft. Ein MVP ist ein Testballon – und wenn er sein Ziel erreicht hat, kann es sehr wohl sinnvoll sein, ihn auf Basis der gewonnenen Erkenntnisse komplett neu zu konzipieren. Wichtig ist nur, dass man nicht aus reinem Perfektionismus handelt, sondern weil man realistisch einschätzt, dass der alte Code das Startup eher aufhält als voranbringt.