Vierzig Zeilen auf einem Whiteboard, und noch kein Nutzer
Am Ende des Workshops steht eine Liste. Vierzig Features, jedes einzelne sinnvoll begründet, jedes von jemandem im Raum gewünscht.
Niemand hat gefragt, welche eine Frage das erste Release eigentlich beantworten soll.
Genau hier gehen die meisten MVPs verloren. Nicht am Stack, nicht am Team, nicht am Budget. Am Umfang.
Ein Minimum Viable Product ist die kleinste ausgelieferte Version Ihrer Idee, mit der echte Nutzer eine echte Aufgabe erledigen können. Kein Klickmodell, keine abgespeckte Version 1.0. Laufende Software mit dem kleinstmöglichen Funktionsumfang.
MVP-Entwicklung ist deshalb vor allem eine Schnittentscheidung. Der Code ist der einfachere Teil.
Das erste Release beantwortet eine Frage, nicht zehn
Schreiben Sie die Frage auf, bevor Sie das Backlog öffnen. Ein Satz, an die Wand, sichtbar für alle.
“Erfassen Handwerksbetriebe ihre Angebote per Sprachnotiz, wenn das Werkzeug daraus ein versandfertiges PDF macht?” Das ist eine Frage.
“Ob unsere Plattform am Markt funktioniert” ist keine. Sie lässt sich durch kein Release beantworten, und weil sie alles umfasst, rechtfertigt sie auch jedes Feature.
Eine brauchbare Frage hat zwei Eigenschaften. Sie benennt ein beobachtbares Verhalten, und sie kann mit “nein” beantwortet werden.
Danach wird das Priorisieren mechanisch. Trägt ein Feature zur Antwort bei? Wenn nicht, wandert es auf die Warteliste, ohne Diskussion.
Das spart mehr Zeit, als es klingt. Die teuersten Wochen eines Projekts sind selten die mit dem meisten Code, sondern die mit den längsten Meetings über Geschmacksfragen.
Die Schnittlinie verläuft längs, nicht quer
Der häufigste Schnittfehler sieht vernünftig aus: Man nimmt alle geplanten Bereiche und baut von jedem die Hälfte. Angebote halb, Rechnungen halb, Kundenverwaltung halb.
Das Ergebnis ist Software, mit der niemand arbeiten kann. Drei halbe Brücken bringen Sie nicht über den Fluss.
Schneiden Sie stattdessen längs. Ein Arbeitsablauf, vollständig, von der ersten Eingabe bis zu dem Ergebnis, das den Nutzer tatsächlich interessiert.
Für das Angebotswerkzeug heißt das: Anfrage aufnehmen, Positionen erzeugen, Angebot als PDF verschicken. Ende.
Keine Rechnungsstellung, keine Mahnläufe, keine Kundenhistorie, keine Auswertungen. Alles, was neben dem Pfad liegt, wartet.
Der Gewinn ist nicht nur Geschwindigkeit. Ein vollständiger Pfad erzeugt echte Nutzung, und echte Nutzung ist die einzige Quelle, die Ihnen sagt, ob die Annahme trägt.
Ein halber Pfad erzeugt dagegen nur höfliche Rückmeldungen. Menschen sind nett zu unfertigen Dingen, die sie nicht wirklich benutzen müssen.
Welcher Arbeitsablauf zuerst?
Meistens stehen zwei oder drei Kandidaten zur Wahl. Drei Kriterien sortieren sie zuverlässig.
Wo ist der Schmerz am schärfsten? Nicht am größten, sondern am schärfsten. Ein Ablauf, den jemand zweimal täglich verflucht, schlägt einen, der einmal im Quartal nervt.
Können Sie sehen, dass jemand fertig geworden ist? Ein Ablauf mit einem klaren Endpunkt, etwa einem versendeten Dokument, liefert ein eindeutiges Signal. Ein Ablauf, der in “der Nutzer schaut sich das an” endet, liefert keins.
Und hängt der Ablauf an den anderen? Wählen Sie den, der allein funktioniert. Wer mit dem Teil beginnt, der Daten aus drei noch nicht gebauten Bereichen braucht, hat den Schnitt schon verloren.
Fällt die Wahl schwer, ist das selten ein Zeichen von Gleichwertigkeit. Meistens ist die Frage aus dem ersten Abschnitt noch zu unscharf formuliert.
Prototyp, MVP und Pilot sind drei verschiedene Dinge
Diese drei Begriffe werden in Angeboten munter vermischt, und die Verwechslung kostet regelmäßig ein Quartal. Eine verbindliche Definition gibt es für keinen davon, deshalb hier die Grenze, die wir in Projekten ziehen.
Ein Prototyp simuliert. Klickmodell in Figma, Wegwerf-Skript, Demo mit fest verdrahteten Daten. Er beantwortet Fragen zur Bedienung und wird danach weggeworfen.
Ein MVP funktioniert. Es läuft in Produktion, verarbeitet echte Daten echter Nutzer und wird weiterentwickelt.
Ein Pilot ist fertige Software mit begrenztem Nutzerkreis. Die Frage ist hier nicht mehr “will das jemand”, sondern “hält das im Betrieb”.
Der Klassiker: Ein Team baut monatelang einen Prototyp, nennt ihn MVP und stellt beim Übergang in den Betrieb fest, dass nichts davon tragfähig ist. Der Prototyp war gut. Er war nur nie als Fundament gedacht.
Was ins erste Release gehört und was wartet
| Ins erste Release | Wartet |
|---|---|
| Der eine Arbeitsablauf, vollständig | Jeder zweite und dritte Arbeitsablauf |
| Anmeldung über einen fertigen Dienst | Rollen- und Rechtekonzept, SSO |
| Ein Datenmodell, das sich migrieren lässt | Auswertungen und Dashboards |
| Ausliefern und ein geprobter Rollback | Mehrsprachigkeit, mobile App |
| Eine einfache Nutzungsmessung | Self-Service-Abrechnung, Importassistenten |
| Absicherung der erhobenen Daten | Admin-Oberfläche (die Konsole reicht) |
Die rechte Spalte ist der eigentliche Inhalt dieser Tabelle. Jede Zeile dort hat schon einmal ein erstes Release um Wochen verzögert.
Besonders hartnäckig ist die Admin-Oberfläche. Solange Sie zwanzig Nutzer haben, erledigt eine Konsole jede Verwaltungsaufgabe, die sonst zwei Wochen Oberflächenarbeit bedeutet hätte.
Zwei Dinge stehen allerdings nie auf der Warteliste.
Das erste ist alles, was Daten verlieren kann. Ein MVP darf hässlich sein und Lücken haben. Es darf die Arbeit eines Nutzers nicht auffressen.
Das zweite ist der Umgang mit personenbezogenen Daten. Die DSGVO kennt keine Erprobungsphase, und was Sie in den ersten Wochen an Datenflüssen anlegen, dokumentieren Sie später nur mühsam nach.
MVP-Software: kaufen, wo Sie sich nicht unterscheiden
Die Frage “welche Software brauche ich für mein MVP” hat eine langweilige Antwort. Möglichst wenig eigene.
Anmeldung, Zahlungsabwicklung, E-Mail-Versand, Fehler-Tracking, Nutzungsmessung. Für jeden dieser Bausteine gibt es fertige Dienste, deren Anbindung Tage kostet statt Wochen.
Keiner davon ist Ihr Alleinstellungsmerkmal. Niemand kauft Ihr Produkt wegen des Login-Formulars.
Bauen Sie den Teil selbst, wegen dem jemand Sie anruft. Alles andere mieten Sie. Genau diese Aufteilung beschreibt unsere Entscheidungshilfe zwischen Eigenentwicklung und Standardsoftware: Standardlösungen für die Routine, Eigenbau für den Wettbewerbsvorteil, APIs als Bindeglied.
Eine Einschränkung gehört dazu. Jeder eingebundene Dienst, der personenbezogene Daten in Ihrem Auftrag verarbeitet, braucht einen Auftragsverarbeitungsvertrag. Für seine eigenen Unterauftragsverarbeiter haftet er Ihnen gegenüber zwar selbst, kennen und genehmigen müssen Sie die Kette trotzdem.
Wie diese Kette aussieht und was darin geregelt sein muss, steht in unserem Beitrag zum Auftragsverarbeitungsvertrag. Wer die Liste der Dienste von Anfang an pflegt, spart sich die Rekonstruktion beim ersten Kundenaudit.
Fertig genug: drei Kriterien statt einer Feature-Liste
Wann ist ein MVP fertig? Nicht, wenn die Liste leer ist. Die Liste wird nie leer.
Drei Kriterien reichen aus.
Erstens: Ein Mensch außerhalb Ihres Teams kommt allein durch den Pfad. Ohne Anruf, ohne Bildschirmfreigabe, ohne Ihre Erklärung nebenbei.
Zweitens: Sie können einen Fehler am selben Tag beheben und ausliefern. Ein MVP mit zweiwöchigem Releasezyklus lernt nicht, es wartet.
Was dafür minimal nötig ist, beschreibt unser Beitrag zur kleinsten CI/CD-Pipeline, die wöchentliche Releases trägt: Tests auf dem Merge Request, ein jederzeit deploybarer Hauptzweig, ein geprobter Rollback.
Drittens: Sie sehen in Daten, wie weit Nutzer kommen. Wer bricht wo ab? Ohne diese Antwort haben Sie ausgeliefert und trotzdem nichts gelernt.
Fehlt eines der drei Kriterien, ist das Release nicht fertig. Fehlt ein Feature von der Liste, ist es meistens egal.
“Gut genug” gilt dabei nicht überall gleich. Anmeldung, Zahlungen und der Umgang mit personenbezogenen Daten vertragen keine Abkürzung, weil ein Fehler dort nicht nur Ihr Experiment beschädigt.
Zeit und Geld: Womit Sie bei MVP-Entwicklung rechnen sollten
Zwei Zahlen wollen alle wissen, und beide hängen fast ausschließlich am Umfang.
Zur Dauer eine Faustregel: Braucht Ihr erstes Release länger als ein Quartal, ist es kein MVP mehr. Dann bauen Sie Version 1.0 und nennen sie nur anders.
Diese Grenze ist kein Naturgesetz, sondern eine Disziplinmaßnahme. Sie erzwingt den Schnitt, statt ihn zu vertagen.
Mehr Leute helfen dabei wenig. Ein einzelner Arbeitsablauf lässt sich schlecht auf sechs Personen aufteilen, und der Abstimmungsaufwand frisst den Rest.
Beim Budget hilft der Blick auf die Gesamtspanne. Unsere Übersicht, was individuelle Softwareentwicklung kostet, nennt für KMU-Projekte Stand 2026 etwa 50.000 bis 250.000 EUR. Ein sauber geschnittenes MVP liegt am unteren Rand dieser Spanne.
Der Tagessatz ist der schwächere Hebel. Ein halbierter Umfang spart mehr als jeder ausgehandelte Rabatt, und er spart sofort.
Wer baut, entscheidet ebenfalls mit. Unser Leitfaden zur Bewertung von Softwareentwicklungspartnern nennt als Qualitätsmerkmal, dass gute Anbieter beim Zuschneiden des Umfangs helfen, bevor sie verkaufen. Wer Ihre Vierzig-Feature-Liste kommentarlos in ein Angebot übernimmt, hat Ihnen gerade eine Auskunft gegeben.
Die Kosten, die am häufigsten überraschen, entstehen nach dem Release. Support, Korrekturen, die zweite Iteration.
Planen Sie dieses Budget von Anfang an ein. Sonst steht der Topf genau in dem Moment bei null, in dem Sie zum ersten Mal wirklich wissen, was zu bauen wäre.
Drei Fehler, die aus einem MVP ein Altsystem machen
Der MVP, der heimlich Version 1.0 ist
Der Umfang wächst nie in einer Entscheidung. Er wächst in fünfzehn kleinen, von denen jede für sich vernünftig klingt.
Die Gegenmaßnahme ist banal und funktioniert trotzdem: die sichtbare Warteliste. Jeder Wunsch kommt darauf, niemand verliert sein Thema, und der Schnitt hält.
Das Datenmodell als Wegwerfteil
Code können Sie wegwerfen. Daten nicht.
Eine improvisierte Oberfläche ersetzen Sie in zwei Wochen. Eine Struktur, in der alles in einem JSON-Feld liegt, weil es schnell gehen musste, begleitet Sie durch jede Migration der nächsten Jahre.
Nehmen Sie sich für die drei bis vier zentralen Tabellen einen Nachmittag mehr Zeit. Das ist die einzige Stelle im MVP, an der Nachdenken vor Geschwindigkeit geht.
Abkürzungen ohne Liste
Abkürzungen sind im MVP richtig. Unsichtbare Abkürzungen sind es nicht.
Der Unterschied zwischen bewusster und versehentlicher technischer Schuld ist eine Datei im Repository, in der steht, was Sie warum übersprungen haben.
Ohne diese Liste sammelt sich still an, was unser Beitrag über die wahren Kosten technischer Schulden beschreibt: Jede Abkürzung macht das nächste Feature schwieriger, bis Teams mit hoher Schuldenlast spürbar langsamer liefern als ihre Wettbewerber.
Nach dem ersten Release beginnt die eigentliche Arbeit
Die ersten Wochen nach dem Start entscheiden mehr als die Monate davor. Jetzt beantwortet sich Ihre Frage, und zwar mit Nutzung statt mit Meinungen.
Der zweite Schnitt ist schwerer als der erste. Sie haben jetzt Nutzer, die Wünsche äußern, und jeder Wunsch klingt nach Ihrer Zielgruppe.
Fünf Menschen, die unabhängig voneinander dasselbe verlangen, sind ein Signal. Einer, der laut ist, ist es nicht.
Und wenn die Antwort auf Ihre Frage “nein” lautet? Dann hat das MVP genau das geleistet, wofür es gebaut wurde, zu einem Bruchteil dessen, was Version 1.0 gekostet hätte.
Das ist kein Trostpreis. Das ist der ganze Zweck der Übung.
Sie haben eine Idee und wollen wissen, was realistisch in ein erstes Release passt? Sprechen wir darüber. Unverbindlich, und am Ende wissen Sie, was Sie zuerst bauen.
