MVP steht für Minimum Viable Product, auf Deutsch etwa minimal überlebensfähiges Produkt. Der Begriff fällt, sobald es um den Start einer Software geht, und meistens ist damit eine erste Version gemeint. Die Anwendung, nur mit weniger Funktionen.
Allen Holub erinnert daran, dass es zwei Definitionen gibt. Die ältere, die von Frank Robinson, macht daraus tatsächlich ein Produkt. An sie denken die meisten. Die andere stammt von Eric Ries, aus Lean Startup, und Holub fasst sie so zusammen: „the minimum thing that tests the viability of a product idea“. Das Kleinste, womit sich die Tragfähigkeit einer Produktidee testen lässt.
Es ist keine Version 1. Es ist überhaupt kein Produkt. Es ist ein Test.
Ein MVP beantwortet eine einzige Frage: Lohnt es sich, dieses Produkt zu entwickeln? Besteht es den Test, ist die Idee tragfähig, und es ist sinnvoll, mit dem Bau zu beginnen. Fällt es durch, erspart man sich Monate, in denen man etwas baut, das niemand will.
Das ideale MVP erfordert laut Holub gar keine Entwicklung. Sein Beispiel: Das MVP von DoorDash bestand darin, Pizzas auszuliefern. Damit wurde getestet, ob sich Essenslieferungen nach Hause tragen, ohne eine Zeile Code.
Braucht es doch Code, bleibt es winzig. Holub spricht von einem MVP, das „in a day or two, maybe a couple of weeks on the outside“ steht. Dafür greift er die Methode von Ries auf: den kleinsten denkbaren Funktionsumfang nehmen, ihn halbieren, dann noch einmal halbieren, und dann noch einmal. Und immer nur eine Sache auf einmal testen.
In einem neueren Beitrag zieht er die Grenze noch enger. Ein Software-MVP, dessen Bau und Veröffentlichung mehr als ein paar Tage dauern, ist ihm zufolge viel zu groß.
Weil niemand im Voraus weiß, welche Ideen funktionieren werden. Wenn Microsoft die Wirkung seiner Ideen per kontrolliertem Experiment misst, verbessert nur eine von drei die Zielmetrik. Ein Drittel hat keine Wirkung, ein Drittel verschlechtert sie (Kohavi und Thomke, Harvard Business Review, 2017). Niemand weiß im Voraus, welche. Das zeigt erst die Nutzung.
Ohne Test zeigt es sich erst, wenn schon gebaut ist.
Ein App-Gründer hat davon in einem Video erzählt. Ende 2024 bringt er eine Online-Software heraus, die er drei bis vier Monate lang öffentlich aufbaut. Er beauftragt einen Entwickler, für 25.000 €, und eine Grafikerin. Zum Start melden sich viele an. Doch es fehlen Funktionen, die sie für unverzichtbar halten. Das Geld ist aufgebraucht, die Einnahmen der App decken ihre Kosten nicht, und er legt sie auf Eis.
Diese Geschichte sagt nichts über die Qualität der geleisteten Arbeit. Sie sagt etwas anderes. Das Budget wurde für eine Funktionsliste gebunden, noch bevor es die geringste Rückmeldung von Nutzern gab. Was die Nutzer brauchten, erfuhr er beim Start. Da war kein Geld mehr übrig, um es zu bauen.
Alle drei ähneln sich: klein, schnell, oft unvollständig. Sie räumen aber nicht denselben Zweifel aus.
Das MVP beantwortet die Frage: Hat dieses Produkt eine Daseinsberechtigung? Was man davon behält, ist die Antwort.
Der Prototyp beantwortet eine andere: Funktioniert dieser Entwurf so, wie wir glauben? Eine Bildschirmskizze am Whiteboard ist einer. Ein Modell, das testet, wie sich ein Teil des Programms unter Last verhält, ist ein anderer. Dieser muss in Produktionsqualität geschrieben sein, da er anschließend in die Codebasis einfließt. Holub fasst den Unterschied in zwei Sätzen zusammen: „A prototype tests a design. An MVP determines if a product is worth building.“
Der Proof of Concept kommt noch früher. Er prüft, ob eine technische Entscheidung, die noch zur Debatte steht, tragen wird. Bezweifelt man, dass die Datenbank die Last verkraftet, schreibt man ein Programm, das nichts anderes tut, als Daten hineinzuschreiben und wieder auszulesen. Das Ergebnis hat mit der fertigen Software nichts gemein.
Der Spike schließlich stammt aus dem Vokabular von Jez Humble und Dave Farley. In Continuous Delivery (S. 425) ist er eine Wegwerf-Implementierung einer bestimmten Anforderung, die ein Analyse-, Entwicklungs- oder Testrisiko verringern soll. Der Code wird weggeworfen. Nur die Antwort zählt.
Das richtige Werkzeug zu wählen heißt zuerst, den eigenen Zweifel zu benennen. Ein Zweifel am Nutzen verlangt nach einem MVP. Ein Zweifel am Entwurf nach einem Prototyp. Ein Zweifel an der technischen Machbarkeit nach einem Proof of Concept oder einem Spike.
Holub beschreibt zwei Schulen.
Die erste will das MVP so schnell wie möglich potenziellen Kunden in die Hand geben. Der Code darf schludrig sein. Er ist zum Wegwerfen gedacht, und auf dieses Wort kommt es an. Diese Schule wettet darauf, dass die Idee scheitert, und gibt deshalb so wenig wie möglich aus.
Die zweite behandelt das MVP als Kern eines „Walking Skeleton“: des ersten Stücks eines Systems, das danach in kleinen Schritten wächst. Sie wettet darauf, dass die Idee funktioniert. Der Code muss also von Anfang an Produktionsqualität haben. Der Umfang bleibt winzig, und nach Holubs Erfahrung ist guter Code schneller gebaut als schludriger.
Beide lassen sich vertreten. Sie zu vermischen nicht. „These two approaches cannot coexist“, schreibt Holub. Wer ein MVP von schlechter Qualität zum Kern eines Systems macht, baut auf einem faulen Kern, den er nicht mehr loswird.
In seinem Beitrag vom September 2026 neigt er zur zweiten Schule. Das MVP in Produktionscode zu bauen, mit Tests und einer ordentlichen Oberfläche, kostet ihm zufolge nur etwa einen Tag mehr. Und das Ergebnis dient danach als Walking Skeleton.
Dave Farley zieht einem Big Upfront Design einen Entwurf vor, der sich in kleinen Schritten weiterentwickelt (Video „How To Avoid Big Upfront Design“, Kanal Modern Software Engineering). Aus unserer Sicht folgt ein in Produktionscode gebautes MVP diesem Weg: Es wächst Schritt für Schritt, statt vollständig im Voraus entworfen zu werden.
Was die erste Schule von Hand programmierte, erzeugen heute KI-Tools. Man beschreibt die gewünschte Anwendung, ohne den Code zu lesen, den die KI schreibt: Das ist Vibe Coding. Holub räumt ihm einen Platz ein, den der Wegwerf-Prototypen.
Dort ist auch der App-Gründer angekommen. 2025 entdeckt er Vibe Coding und schätzt, dass es ihn zwei Tage gekostet hätte, für 0 €. In einem Punkt deckt sich seine Rechnung mit der von Holub: Ein Test von wenigen Tagen kann zeigen, was den Nutzern fehlt, bevor das Budget ausgegeben ist.
Doch Wegwerfcode bleibt Wegwerfcode. Der per Vibe Coding entstandene Prototyp beantwortet die Frage nach der Idee. Er wird nicht zum Fundament der Software, die danach kommt. Was ein „es funktioniert“ nicht garantiert, erläutern wir in unserem Artikel über das Erstellen einer App mit KI.
Ein MVP, das besteht, schließt nichts ab. Holub beschreibt, wie es weitergeht. Man stellt das Kleinstmögliche online. Die Reaktion ist fast immer: schön, aber … Dieses „aber“ zeigt die nächste kleinste Änderung an. Man setzt sie um, stellt sie online und fängt von vorn an. Er ergänzt: keine große Spezifikation im Voraus, auch nicht, wenn eine KI sie bekommt.
Diese Schleife endet nicht mit dem Start. In unserem adaptiven Ansatz ist jede Funktion eine Hypothese, die sich an der Wirklichkeit Ihrer Nutzer bewähren muss.
Wir entwickeln Ihre individuelle Anwendung zu einem festen Budget, das am Ende jedes Monats für die geleistete Arbeit abgerechnet wird. Sie ist innerhalb eines Monats nutzbar. Nutzbar heißt nicht fertig: Ihre Teams arbeiten ab dem ersten Monat damit, und diese Nutzung entscheidet, was wir im Folgemonat entwickeln.
Warum nicht von Anfang an alles planen, die Funktionsliste und den Zeitplan? Dieser Frage geht unser Artikel über den prädiktiven und den adaptiven Ansatz nach.
Unser Leitfaden geht ausführlich auf die Experimente von Kohavi ein und darauf, was die Funktionen, die niemand nutzt, später kosten.
Haben Sie eine Idee, die Sie testen möchten, oder eine Software, die Sie entwickeln lassen wollen? Sprechen wir darüber?
Was ist ein Feature Flag? Vier Arten von Toggles, was Sie versuchen sollten, bevor Sie einen hinzufügen, und sieben Anti-Patterns, durch die nie getesteter Code läuft.
App entwickeln lassen: Mit welchem Budget rechnen? Der Betrag allein reicht nicht: Setzen Sie auf ein Ziel statt auf eine Liste, mit Nutzern ab dem ersten Monat.
Prädiktiver oder adaptiver Ansatz? Die eigentliche Trennlinie verläuft nicht zwischen V-Modell und agilem Vorgehen, sondern zwischen Vorhersagen und Anpassen. Was das für Software bedeutet.
