MVP-Umfang festlegen: Was in die erste Version gehört
In die erste Version gehört der eine Ablauf, mit dem ein zahlender Nutzer seine wichtigste Aufgabe von Anfang bis Ende erledigt, plus alles, was sich später nur teuer nachrüsten lässt. Alles andere bekommt einen Auslöser, ab dem es gebaut wird.
Ein Minimum Viable Product ist die kleinste Version einer Software, mit der echte Nutzer eine echte Aufgabe erledigen und dafür bezahlen oder zumindest wiederkommen. Klein heißt dabei schmal, nicht wackelig: Der eine Ablauf muss vollständig funktionieren, von der Anmeldung bis zum Ergebnis. Ein halber Ablauf liefert keine Antwort auf die Frage, ob jemand das Produkt will.
Schwer wird es beim Weglassen. Jede Funktion auf der Wunschliste hat einen guten Grund, und jede kostet Wochen, bevor der erste Nutzer etwas sieht. Was hilft, ist ein festes Raster: eine Aufgabe, ein Ablauf, eine Liste mit Auslösern für alles Spätere und eine kurze Liste von Dingen, die von Anfang an stimmen müssen. Das Arbeitsblatt weiter unten setzt dieses Raster um.
Wer noch klärt, ob ein Mitgründer oder ein Dienstleister die erste Version baut, findet die Abwägung unter Technischer Mitgründer oder Dienstleister. Wie man eine lange Funktionsliste grundsätzlich priorisiert, ist eine eigene Frage; hier geht es um den Schnitt der ersten auslieferbaren Version eines Softwareprodukts.
Zweck
Was ein MVP leisten muss
Ein MVP beantwortet eine Frage, die sich mit Folien und Umfragen nicht beantworten lässt: Nutzen Menschen dieses Produkt für ihre Aufgabe, wenn sie es in die Hand bekommen? Daraus folgen drei Anforderungen an die erste Version.
Sie ist benutzbar ohne Begleitung. Muss jemand aus Ihrem Team neben dem Nutzer sitzen, prüft der Test Ihre Erklärung statt des Produkts.
Sie läuft mit echten Daten im echten Betrieb. Ein Prototyp mit Beispieldaten zeigt, ob eine Oberfläche verständlich ist. Ob jemand seine Kundendaten hineingibt und am nächsten Montag wiederkommt, zeigt erst eine Version, der man Daten anvertrauen kann.
Sie misst, was sie beweisen soll. Vorher steht fest, woran Sie Erfolg erkennen: zum Beispiel zehn Betriebe, die in den ersten vier Wochen jede Woche Termine darüber annehmen.
Ein MVP ist damit kein Sparprodukt und kein Demonstrator für Investoren. Für einen Demonstrator kann ein Klickmodell reichen. Ein MVP dagegen wird betrieben, gepflegt und weiterentwickelt, und deshalb gehört zum Schnitt auch die Frage, was von Anfang an sauber gebaut sein muss.
Schritt 1
Die eine Aufgabe, die gelöst werden muss
Am Anfang steht ein Satz in der Form: „[Wer] erledigt mit dem Produkt [welche Aufgabe] statt bisher mit [welchem Behelf].“ Für eine Buchungssoftware für Kfz-Werkstätten könnte er lauten: „Werkstattinhaber nehmen Reparaturtermine online an, statt sie am Telefon in einen Papierkalender einzutragen.“
Aus diesem Satz leiten Sie den Kernablauf ab, Schritt für Schritt, wie ihn ein Nutzer durchläuft: registrieren, Öffnungszeiten und Leistungen eintragen, Buchungsseite teilen, Anfrage erhalten, bestätigen, Termin im Kalender sehen. Jeder Schritt, ohne den der Ablauf abbricht, gehört in die erste Version. Jeder Schritt, der den Ablauf bequemer, schneller oder schöner macht, kommt auf die Warteliste.
Die Reihenfolge innerhalb des Ablaufs ist ebenfalls eine Entscheidung. Bei einem internen Tools-Portal für ein Münchner Startup haben wir die Dispositionsoberfläche entlang der Begriffe der Fachlichkeit wachsen lassen: zuerst der Kalender mit den Mitarbeitern als Spalten, dann Filter und Sortierung, später die Buchungsabläufe und am Ende die Check-in- und Check-out-Schritte. Davor standen die Schnittstellen für Anmeldung und Personaldaten, auf die beide Oberflächen aufsetzten. Scope und Endpunkt waren von Beginn an klar gesetzt, beschrieben in der Case Study REST-API und HR-Frontend für ein internes Tools-Portal. Für ein MVP heißt das: Zuerst entsteht der Schritt, auf dem die anderen aufbauen. Was im Pitch am besten aussieht, kommt dann an die Reihe, wenn der Ablauf darunter trägt.
Schritt 2
Was getrost warten kann
Auf die Warteliste gehören Funktionen, die der Kernablauf nicht braucht, um zu funktionieren. Typische Kandidaten in Softwareprodukten für Geschäftskunden:
Auswertungen und Dashboards. Solange es zehn Kunden gibt, liefert eine Datenbankabfrage am Monatsende dieselbe Erkenntnis.
Automatische Abrechnung mit Tarifstufen, Gutscheinen und anteiliger Verrechnung. Die ersten Kunden lassen sich von Hand abrechnen.
Eine eigene App für iPhone und Android, wenn die Website auf dem Smartphone benutzbar ist.
Schnittstellen zu weiteren Systemen, solange ein Export als Datei reicht.
Einstellungen für Sonderfälle, die bisher ein einziger Interessent genannt hat.
Feinschliff an der Geschwindigkeit, bevor es Last gibt. Welche Indizes eine Laravel-Anwendung später braucht, lässt sich an echten Abfragen ablesen; wie das geht, steht unter PostgreSQL Indexing für Laravel-Apps.
Warten heißt nicht vergessen. Jede Funktion auf der Liste bekommt einen Auslöser: „sobald drei zahlende Kunden danach fragen“, „ab 50 Rechnungen im Monat“, „wenn ein Kunde mehr als 20 Mitarbeiter einträgt“. So wird aus der Diskussion „brauchen wir das?“ eine Beobachtung, die jeder im Team nachprüfen kann. Was bis dahin fehlt, ersetzt ein Handgriff: eine Mail an den Support, eine Rechnung aus der Buchhaltungssoftware, ein Export per Hand.
Ausnahmen
Was von Anfang an stimmen muss
Einige Dinge kosten in der ersten Version wenig und später viel. Sie gehören deshalb in das MVP, obwohl kein Nutzer sie sieht.
Trennung der Kunden. Wenn das Produkt mehrere Organisationen bedienen soll, trägt jeder Datensatz von Anfang an die Kennung seines Mandanten. Mandantenfähigkeit nachträglich einzubauen berührt fast jede Abfrage. Welches Modell zu welcher Kundenzahl passt, vergleicht Mandantenfähigkeit: Daten in SaaS-Plattformen sauber trennen.
Rechte und Anmeldung. Zwei Rollen reichen am Anfang, aber sie werden an einer Stelle geprüft und nicht in jeder Ansicht einzeln.
Datenschutz und Sicherung. Personenbezogene Daten brauchen eine Rechtsgrundlage, eine Datenschutzerklärung und eine Datensicherung, die schon einmal wiederhergestellt wurde.
Code, Konten und Rechte beim Startup. Repository, Domain, Hosting und Zahlungsanbieter laufen auf das Unternehmen, nicht auf einen Entwickler.
Auf der Seite für Softwarehersteller und SaaS-Startups beschreiben wir dieselbe Linie: keine Über-Architektur im MVP, aber Entscheidungen, die das Wachstum nicht blockieren, mit Mandantentrennung von Tag eins.
Gegenprobe
Wenn der Schnitt zu knapp ausfällt
Ein Schnitt kann auch zu tief gehen. Dann fehlt statt einer Komfortfunktion ein Stück des Ablaufs, das niemand auf der Liste hatte, weil es im Pitch nie vorkommt. Anfällig dafür sind diese Stellen:
Der Einstieg. Ohne Einladung per Mail, Passwort-Zurücksetzen und eine erste Hilfe beim Anlegen kommen Nutzer gar nicht bis zur Aufgabe. Diese Schritte gehören zum Kernablauf, auch wenn sie unscheinbar wirken.
Die Benachrichtigung. Erfährt der Kunde der Werkstatt nicht, dass sein Termin bestätigt ist, ruft er wieder an, und der Test zeigt das alte Verhalten.
Die Hilfe im Hintergrund. Ihr Support braucht eine schlichte Verwaltungsansicht, um ein Konto zu finden, eine Buchung zu korrigieren oder einen Nutzer zu sperren. Ohne sie landet jede Anfrage beim Entwickler.
Der Weg hinaus. Geschäftskunden fragen früh, wie sie ihre Daten wieder herausbekommen. Ein Export als CSV-Datei kostet wenig und nimmt einen Einwand aus dem Verkaufsgespräch.
Eine zweite Quelle für zu viel Umfang sind große Interessenten mit Sonderwünschen. Ein Konzern, der eine Anbindung an sein Personalsystem verlangt, ist ein guter Grund für eine Zeile auf der Warteliste, mit dem Auslöser „unterschriebener Vertrag“. Vor der Unterschrift in den Kernablauf gehört er nicht, sonst baut das Startup ein Einzelstück für einen Kunden, der noch nicht gekauft hat.
Kopieren, ausfüllen und vor dem ersten Angebot mit allen Gründern durchgehen. Das Beispiel ist erfunden.
# MVP-Schnitt: [Produktname]
Stand: [Datum] | Entschieden von: [Namen]
## 1. Die eine Aufgabe
[Wer] erledigt mit dem Produkt [Aufgabe] statt bisher mit [Behelf].
Erfolg heißt: [messbare Zahl, Zeitraum].
## 2. Kernablauf (bricht ohne diesen Schritt ab)
| Nr. | Schritt | Aufwand in Personentagen |
|-----|---------|--------------------------|
| 1 | | |
## 3. Warteliste (mit Auslöser)
| Funktion | Wird gebaut, sobald ... | Bis dahin von Hand |
|----------|-------------------------|--------------------|
## 4. Stimmt von Anfang an
- Mandantenkennung in jedem Datensatz: ja/nein
- Rollen an einer Stelle geprüft: ja/nein
- Datensicherung einmal wiederhergestellt: ja/nein
- Repository, Domain, Konten auf das Unternehmen: ja/nein
## 5. Fertig, wenn
- [Abnahmekriterium für den Kernablauf]
- [erste Nutzer, die es ohne Begleitung schaffen]
----------------------------------------------------------------
BEISPIEL: Online-Terminbuchung für Kfz-Werkstätten
1. Werkstattinhaber nehmen Reparaturtermine online an statt am
Telefon. Erfolg heißt: 10 Werkstätten nehmen in den ersten vier
Wochen jede Woche Termine darüber an.
2. Kernablauf Personentage
1 Registrieren, Einladung, Passwort zurücksetzen,
Werkstatt anlegen, zwei Rollen 4
2 Öffnungszeiten, Leistungen, Dauer je Leistung 4
3 Öffentliche Buchungsseite je Werkstatt 5
4 Anfrage bestätigen oder ablehnen, Mail an Kunde 4
5 Wochenkalender der Werkstatt 4
6 Support-Ansicht (Konto finden, Buchung korrigieren,
Nutzer sperren) und CSV-Export 3
7 Betrieb: Server, Sicherung, Überwachung 3
8 Tests und Abnahme des Ablaufs 3
Summe: 30
3. Warteliste
Online-Bezahlung ab 5 zahlenden Werkstätten | Rechnung von Hand
SMS-Erinnerung wenn Ausfälle gemeldet werden | Mail genügt
Auswertungen ab 30 Werkstätten | Abfrage am Monatsende
App nie ohne Nachfrage | Buchungsseite mobil
4. Mandantenkennung ja, Rollen ja, Sicherung ja, Konten ja
5. Fertig, wenn eine Werkstatt ohne Hilfe vom Anlegen bis zum
ersten bestätigten Termin kommt und der Kunde die Mail erhält.
Rechnung
Was der Schnitt im Beispiel bedeutet
Im Beispiel umfasst der Kernablauf 30 Personentage, darin enthalten Einstieg, Support-Ansicht und Export aus dem Abschnitt davor. Mit dem Tagessatz aus Ihrem Angebot multipliziert, ergibt das den Preis der ersten Version; vergleichen Sie Angebote deshalb zuerst in Personentagen je Zeile, dann in Euro. Die Spannen für typische Vorhaben ordnet Was kostet Individualsoftware? ein.
Der Wert der Rechnung liegt im Vergleich. Kämen Online-Bezahlung, SMS-Erinnerung, Auswertungen und eine App gleich mit hinein, bekäme jede davon eigene Personentage, und der erste zahlende Kunde rückte um genau diese Zeit nach hinten. Allein eine App für zwei Plattformen wäre ein eigenes Vorhaben mit eigener Prüfung in den App-Stores. Jede Zeile der Warteliste ist damit eine Wette, die Sie erst eingehen, wenn ein Auslöser sie bestätigt.
Schritt 3
Wann das MVP fertig ist
Fertig ist das MVP, wenn der Kernablauf ohne Begleitung funktioniert und die erste Gruppe echter Nutzer ihn durchlaufen hat. Das Kriterium steht vorher im Arbeitsblatt, sonst verschiebt es sich mit jeder Rückmeldung.
Drei Prüfungen vor dem Start helfen dabei:
Eine Person, die das Produkt nicht kennt, legt ein Konto an und erledigt die Aufgabe, während Sie nur zuschauen. Notieren Sie jede Stelle, an der sie fragt.
Ein Fehlerfall pro Schritt ist durchgespielt: abgelehnte Anfrage, falsche Eingabe, abgelaufene Anmeldung.
Die Datensicherung ist einmal in eine leere Umgebung zurückgespielt worden.
Wie Sie Abnahmekriterien so formulieren, dass beide Seiten dasselbe darunter verstehen, steht unter Software abnehmen. Danach beginnt die eigentliche Arbeit: beobachten, welche Auslöser auf der Warteliste zuerst eintreten, und genau diese Zeilen als Nächstes bauen.
Erste Version schneiden, bevor Code entsteht
Füllen Sie das Arbeitsblatt aus, bevor Sie Angebote einholen: Dann rechnet jeder Anbieter denselben Kernablauf. Wie wir mit Startups vom ersten MVP bis zur Plattform mit vielen Mandanten arbeiten, steht auf unserer Branchenseite.
Rund um die erste Version
Häufige Fragen
-
Eine allgemeingültige Dauer gibt es nicht, sie folgt aus dem Kernablauf. Verlässlicher ist der umgekehrte Weg: Legen Sie vorher einen festen Zeitrahmen fest und kürzen Sie den Umfang, bis er hineinpasst, statt die Frist zu verlängern. Im Beispiel oben sind es 30 Personentage, bei einer Person in Vollzeit also sechs Arbeitswochen zu je fünf Tagen.
-
Ein MVP darf Lücken haben, aber keine Fehler im Kernablauf. Fehlt eine Komfortfunktion, merkt der Nutzer es und arbeitet trotzdem weiter. Bricht die Buchung ab oder gehen Daten verloren, misst der Test nur noch Ihre Fehler und nicht mehr das Interesse am Produkt.
Nachweise
Quellen und Stand
Stand: 03.09.2026. Das Arbeitsblatt und die Werkstatt-Buchung sind ein erfundenes Beispiel, die Personentage eine Schätzung für dieses Beispiel; das Tools-Portal ist in der verlinkten Case Study beschrieben.
Artikel teilen