MVP in acht Wochen: was hineingehört und was nicht
In ein MVP gehört genau ein Arbeitsablauf von Anfang bis Ende, für genau eine Nutzergruppe — dazu das, was Betrieb und Recht ab dem ersten echten Nutzer verlangen. Alles andere wartet: die Rechtematrix, die eigene Verwaltungsoberfläche, die Anbindung an die Warenwirtschaft, die App, die Auswertungen. Dieser Beitrag schneidet den Umfang konkret — zwei Tabellen, eine Wochenaufteilung und die drei Entscheidungen, die am meisten Zeit sparen. Stand: Oktober 2026.
Warum der Zeitrahmen zuerst feststeht
Die acht Wochen in diesem Beitrag sind ein gesetzter Rahmen, keine erhobene Zahl. Es gibt keine belastbare Erhebung, die sagt, wie lange ein MVP „üblicherweise“ dauert, und wer Ihnen eine nennt, hat sie nicht gemessen. Der Rahmen hat einen anderen Zweck: Er dreht die Frage um. Nicht „wie lange braucht mein Umfang“, sondern „welcher Umfang passt in acht Wochen“. Die erste Frage lässt sich beliebig lange verhandeln, die zweite zwingt zu einer Entscheidung pro Baustein.
Dabei heißt „minimal“ nicht „so wenig wie möglich“. Die Firma, die den Begriff nach eigener Angabe 2001 erstmals benutzt hat, definiert das MVP als „that unique product that maximizes return on risk for both the vendor and the customer“ — als den Punkt zwischen zu wenig und zu viel, nicht als Untergrenze. Produkte ohne die nötigen Funktionen scheitern sofort; Produkte mit zu vielen erhöhen Aufwand und Risiko auf beiden Seiten. Genau darum lässt sich der Schnitt nicht pauschal machen, sondern nur Baustein für Baustein.
Was hineingehört
Sieben Bausteine können nicht warten. Bei jedem steht, warum — und wie seine kleinste tragfähige Form aussieht.
| Baustein | Warum er nicht wartet | Kleinste tragfähige Form |
|---|---|---|
| Ein Arbeitsablauf, durchgängig | Ein halber Ablauf erzeugt Arbeit statt sie zu ersparen: Der Nutzer wechselt mitten im Vorgang zurück in Excel oder ins Mailfach. Nur ein Ablauf, der ein Ergebnis produziert, lässt sich beurteilen. | Vom auslösenden Ereignis bis zum fertigen Ergebnis, auch mit roher Oberfläche und ohne Komfort. |
| Anmeldung mit einer Rolle | Echte Daten ohne Zugangsschutz sind keine Stufe, die man später einbaut. Fehlerhafte Zugriffskontrolle steht in den OWASP Top 10:2025 auf Platz 1. | Benutzername, Passwort, Abmelden, Zurücksetzen über eine Mailadresse. Eine Rolle für alle, die sich anmelden dürfen. |
| Das Datenmodell dieses Ablaufs | Daten überleben jede Oberfläche. Ein falsch geschnittenes Modell wird nicht nachgebessert, sondern mit allen bereits erfassten Daten umgezogen. | Die Tabellen, die dieser eine Ablauf braucht, mit Pflichtfeldern und Beziehungen — nicht mehr. |
| Sicherung und ein geprüfter Rückweg | Eine Sicherung, die nie zurückgespielt wurde, ist eine Vermutung. Artikel 32 Absatz 1 Buchstabe c DSGVO verlangt ausdrücklich die Fähigkeit, Verfügbarkeit und Zugang „bei einem physischen oder technischen Zwischenfall rasch wiederherzustellen“. | Täglich automatisch, außerhalb des Servers gelagert, und einmal vor dem Produktivstart echt zurückgespielt. |
| Fehlerprotokollierung mit Benachrichtigung | Ein Fehler, den niemand sieht, wird vom Nutzer gemeldet — oder gar nicht. Ohne Protokoll können Sie die 72-Stunden-Meldung nach Artikel 33 DSGVO nicht beurteilen. In den OWASP Top 10:2025 steht „Security Logging and Alerting Failures“ auf Platz 9. | Fehler mit Zeitstempel und Zusammenhang in eine Datei oder einen Dienst, dazu eine Mail an einen Menschen bei schweren Fehlern. |
| Ein wiederholbarer Weg auf den Server | Wird von Hand ausgeliefert, kostet jede Korrektur in der Abnahmewoche einen halben Tag und erzeugt Zustände, die niemand nachstellen kann. | Ein Skript oder eine Pipeline, die aus dem Quellstand eine lauffähige Fassung macht — zweimal nacheinander mit gleichem Ergebnis. |
| Die Pflichten ab dem ersten echten Nutzer | Sie hängen am ersten echten Datensatz, nicht am Funktionsumfang. Nachträglich sind sie keine Programmierarbeit, sondern eine Nachdokumentation unter Zeitdruck. | Datenschutzhinweis, Verzeichnis der Verarbeitungstätigkeiten, Auftragsverarbeitungsverträge, Löschkonzept für diesen einen Ablauf. |
Was wartet
Diese zehn Bausteine kommen in fast jedem Anforderungsgespräch vor und können fast immer warten. Die rechte Spalte ist der Punkt: Warten heißt nicht, dass die Anforderung verschwindet, sondern dass sie im MVP anders gelöst wird.
| Baustein | Warum er warten darf | Was Sie stattdessen tun |
|---|---|---|
| Rechte- und Rollenmatrix | Die Trennung ist am Anfang organisatorisch, nicht technisch: Im MVP arbeiten wenige, bekannte Personen. | Eine Rolle. Wer angemeldet ist, darf diesen Ablauf vollständig. |
| Eigene Verwaltungsoberfläche | Sie wird von einer Handvoll Menschen benutzt, die Sie erreichen können — und kostet so viel wie der Ablauf selbst. | Datenbankzugriff oder ein Kommandozeilenbefehl, bedient von einer benannten Person. |
| Mandantentrennung | Sie wartet, weil im MVP ein Mandant arbeitet — nachträglich ist sie allerdings ein Umbau und kein Nachtrag, also gehört die Entscheidung in die Planung. | Ein Mandant, und die Trennung als erste Ausbaustufe eingeplant. |
| Anbindung an ERP oder Warenwirtschaft | Der Testzugang, die Freigabe des Herstellers und die Frage, welches System führt, kosten mehr Wochen als die Programmierung. | Export und Import als Datei, täglich oder auf Knopfdruck. |
| App fürs Handy | Eine eigene App verdoppelt Auslieferung, Prüfung und Fehlersuche. | Eine Weboberfläche, die auf dem Telefon bedienbar ist. |
| Zweite Sprache | Mehrsprachigkeit betrifft jeden Text, jede Mail und jedes Datum — und niemand kann sie vor dem ersten Nutzer beurteilen. | Eine Sprache, aber Texte von Anfang an nicht fest in den Code schreiben. |
| Einmalanmeldung über den Firmenzugang | Hängt an Ihrer IT und an Freigaben, nicht an der Anwendung. | Eigene Anmeldung, der Umstieg bleibt möglich. |
| Auswertungen und Kennzahlen | Vor dem ersten echten Nutzer gibt es nichts auszuwerten, und die interessanten Fragen kennt man erst danach. | Daten vollständig und mit Zeitstempel erfassen. Auswerten kann man später, nachträglich erfassen nicht. |
| Einstellungsseiten | Jede Einstellung ist ein zusätzlicher Zustand, der getestet werden muss. | Werte fest im System, Änderung durch die Entwicklung. |
| Selbstbedienung bei Abo und Rechnung | Bei wenigen Kunden ist die Rechnung von Hand günstiger als die Zahlungsanbindung. | Rechnung aus der Buchhaltung, Zugang von Hand freischalten. |
Die Pflichten, die ab dem ersten echten Nutzer gelten
Das ist der Teil, der am häufigsten in die zweite Stufe geschoben wird — und der sich am wenigsten dafür eignet. Sobald die erste echte Person im System arbeitet, verarbeiten Sie personenbezogene Daten und schulden das volle Programm, unabhängig davon, dass das System „noch ein MVP“ ist.
Vier Pflichten betreffen den Bau unmittelbar. Die Informationspflicht nach Artikel 13 DSGVO greift „bei Erhebung von personenbezogenen Daten bei der betroffenen Person“ — der Datenschutzhinweis muss also dort stehen, wo das Formular steht, nicht irgendwann im Impressum. Artikel 32 verlangt „geeignete technische und organisatorische Maßnahmen, um ein dem Risiko angemessenes Schutzniveau zu gewährleisten“, und nennt dabei ausdrücklich Pseudonymisierung und Verschlüsselung, die dauerhafte Sicherstellung von Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit sowie die rasche Wiederherstellbarkeit nach einem Zwischenfall. Artikel 25 verpflichtet zu Datenschutz durch Technikgestaltung und datenschutzfreundlichen Voreinstellungen — das ist der Artikel, den man im MVP noch billig erfüllt und nach dem Produktivstart teuer. Und Artikel 33 gibt Ihnen im Fall einer Datenschutzverletzung „unverzüglich und möglichst binnen 72 Stunden“ Zeit für die Meldung an die Aufsichtsbehörde; wer keine Protokollierung hat, kann in dieser Frist nicht einmal beurteilen, ob eine Meldung nötig ist.
Beim Verzeichnis von Verarbeitungstätigkeiten nach Artikel 30 glauben viele Mittelständler, die Ausnahme für kleine Unternehmen zu treffen. Sie ist enger, als sie aussieht: Nach Artikel 30 Absatz 5 entfällt die Pflicht für Unternehmen mit weniger als 250 Mitarbeitern nur, „sofern die von ihnen vorgenommene Verarbeitung nicht ein Risiko für die Rechte und Freiheiten der betroffenen Personen birgt, die Verarbeitung nicht nur gelegentlich erfolgt oder nicht die Verarbeitung besonderer Datenkategorien gemäß Artikel 9 Absatz 1 bzw. die Verarbeitung von personenbezogenen Daten über strafrechtliche Verurteilungen und Straftaten im Sinne des Artikels 10 einschließt“. Eine Anwendung, die täglich benutzt wird, verarbeitet nicht „nur gelegentlich“. Rechnen Sie also mit der Pflicht, und schreiben Sie die zwei Seiten für diesen einen Ablauf, solange es ein Ablauf ist.
Dazu kommen die Rechte der Betroffenen, die ab dem ersten Nutzer beantwortbar sein müssen: Auskunft nach Artikel 15 und Löschung nach Artikel 17. Beides ist im MVP eine Frage an das Datenmodell — können Sie alle Daten einer Person finden und entfernen, ohne den Ablauf zu zerstören?
Zwei weitere Rechtsgebiete treffen nur bestimmte MVPs. Das Barrierefreiheitsstärkungsgesetz gilt nach § 1 Absatz 3 unter anderem für „Dienstleistungen im elektronischen Geschäftsverkehr“, die für Verbraucher erbracht werden — also für den Verkauf an Privatpersonen über Web oder App, nicht für eine interne Anwendung oder ein reines B2B-Werkzeug; § 3 Absatz 3 nimmt außerdem Kleinstunternehmen aus, und Kleinstunternehmen ist nach § 2 Nummer 17 nur, wer weniger als zehn Personen beschäftigt und entweder höchstens 2 Millionen Euro Jahresumsatz oder höchstens 2 Millionen Euro Jahresbilanzsumme hat — beide Bedingungen zusammen, nicht eine von beiden. Und erzeugt Ihr MVP KI-Ausgaben, gilt die Kennzeichnungspflicht aus Artikel 50 der KI-Verordnung seit dem 2. August 2026; Einzelheiten und fertige Hinweissätze stehen in KI-Kennzeichnungspflicht: was Artikel 50 verlangt.
Die acht Wochen als Aufteilung
Die Tabelle ist aus dem Schnitt oben abgeleitet, nicht aus einer Erhebung. Sie zeigt, wie der Umfang in den gesetzten Rahmen passt — nicht, wie lange Ihr Vorhaben dauert. Eine ganze Woche gehört der Abnahme mit echten Daten; wer sie streicht, streicht die Antwort auf die Frage, die das MVP beantworten sollte.
| Woche | Ergebnis am Ende der Woche |
|---|---|
| 1 | Der Ablauf ist Schritt für Schritt aufgeschrieben, die eine Nutzergruppe ist benannt, das Datenmodell passt auf ein Blatt. Der Weg auf den Server läuft einmal durch. |
| 2 | Anmeldung mit einer Rolle, Datenmodell in der Datenbank, die erste Maske speichert etwas. |
| 3 | Der Ablauf ist bis zur Hälfte begehbar, mit echten Feldern statt Platzhaltern. |
| 4 | Der Ablauf ist durchgängig: vom auslösenden Ereignis bis zum Ergebnis, roh, aber vollständig. |
| 5 | Grenzfälle: Abbruch, falsche Eingabe, zweiter Anlauf, gleichzeitige Bearbeitung. Fehlerprotokollierung und Benachrichtigung stehen. |
| 6 | Betrieb und Recht: Sicherung samt einmal echt geprüftem Rückweg, Datenschutzhinweis, Verzeichnis, Auftragsverarbeitungsverträge, Löschweg. |
| 7 | Abnahme mit echten Daten durch zwei oder drei echte Nutzer, die ihre eigene Arbeit machen. Fundstellen werden gesammelt, nicht sofort behoben. |
| 8 | Die Fundstellen aus Woche 7 sind nachgezogen oder bewusst vertagt, das System läuft produktiv, jemand schaut zwei Wochen täglich in die Protokolle. |
Die drei Schnitte, die am meisten Zeit sparen
Erstens: eine Nutzergruppe statt zwei. Das ist der größte Hebel, und er wird fast immer übersehen, weil zwei Gruppen nach „nur ein paar Masken mehr“ aussehen. Teuer sind nicht die Masken, sondern die Übergabe zwischen den Gruppen: Wer sieht wann, dass etwas auf ihn wartet? Was passiert, wenn der Zweite ablehnt, zurückgibt, nichts tut? Diese Zustände muss jemand erfinden, bauen, testen — und zwar bevor irgendein echter Nutzer sagen konnte, ob die Richtung stimmt. Entscheiden Sie sich für die Gruppe, deren Arbeit messbar ist, und bedienen Sie die zweite im MVP mit einer Mail oder einer Liste, die jemand ausdruckt. Kommt die zweite Gruppe später dazu, haben Sie einen laufenden Ablauf, an dem Sie die Übergabe entwerfen können, statt ihn auf dem Papier zu erfinden.
Zweitens: eine Rolle statt einer Rechtematrix. Ein Rechtemodell ist kein Bildschirm, es ist eine Bedingung in jeder Abfrage. Wird es nachgezogen, ist das kein Nachtrag, sondern ein Umbau, weil die Prüfung „darf diese Person das sehen“ an dutzenden Stellen eingezogen werden muss — wir haben das in Kundenportal entwickeln lassen: Umfang und Fallen als den teuersten Baustein überhaupt beschrieben. Im MVP arbeiten wenige, namentlich bekannte Personen; dort ist die Trennung eine Absprache, keine Abfrage. Eine Einschränkung: Wenn schon im ersten Ablauf jemand mitarbeitet, der bestimmte Daten nicht sehen darf — ein externer Dienstleister, ein Werkstudent, der Steuerberater —, dann ist die zweite Rolle kein Komfort, sondern der Schnitt liegt falsch. Dann lieber diesen Beteiligten aus dem MVP herausnehmen.
Drittens: Export statt Schnittstelle. Eine Schnittstelle ist keine Leitung, sondern ein Paket: Testzugang, Freigabe durch den Hersteller, Abgleichtakt, Verhalten bei Zeitüberschreitung, Notlauf, und die Festlegung, welches System die führende Quelle ist, wenn zwei dieselbe Kundenadresse kennen. Diese Punkte hängen an Terminen anderer Leute und sind der häufigste Grund, warum ein Zeitplan kippt. Prüffrage für den Schnitt: Trifft der Nutzer im Ablauf eine Entscheidung, die mit den Zahlen von gestern Abend falsch wäre? Bei Bestand, Kreditlimit oder Auftragsstand in der laufenden Produktion ist die Antwort ja — alles andere verträgt eine Datei. Entscheiden Sie das je Datenart, nicht für das ganze Vorhaben.
Woran ein MVP scheitert
„Nur noch dieses eine Feld.“ Der Umfang wächst nicht durch Entscheidungen, sondern durch Nebensätze in Besprechungen. Gegenmittel: eine einzige schriftliche Liste für alles, was nach dem Start kommt. Jeder Wunsch wird aufgenommen — in die Liste, nicht in den Bau. Die Liste ist später der Plan für die zweite Stufe, und sie beruhigt zuverlässiger als eine Diskussion.
Abnahme ohne echte Daten. Beispieldaten sind sauber, vollständig und plausibel. Echte Daten haben Umlaute in Dateinamen, fehlende Postleitzahlen, zwei Kunden mit demselben Namen und Mengen mit fünf Nachkommastellen. Gegenmittel: Woche 7 läuft mit echten Daten im Produktivsystem, und die Nutzer machen ihre eigene Arbeit, nicht ein Testdrehbuch.
Der Prototyp, der still zum Produktivsystem wird. Jemand füllt das Klickmodell „nur kurz“ mit echten Daten, und drei Monate später hängt der Vertrieb daran — ohne Sicherung, ohne Protokoll, ohne Datenschutzhinweis. Gegenmittel: am Anfang festlegen, was das Ding ist. Ein Prototyp darf nichts dauerhaft speichern; ein MVP bekommt vom ersten Tag an die sieben Bausteine aus der ersten Tabelle.
Der Umfang ist als Funktionsliste beschrieben, nicht als Ablauf. Eine Liste aus zwanzig Stichworten lässt sich nicht schneiden, weil niemand sagen kann, welche fünf zusammen ein Ergebnis erzeugen. Gegenmittel: Schreiben Sie den Ablauf als Sätze mit einem Auslöser und einem Endzustand — „Ein Kunde schickt eine Anfrage per Mail; am Ende liegt ein freigegebenes Angebot im System und der Kunde hat es als PDF.“ Alles, was in diesen Sätzen nicht vorkommt, ist Stufe zwei.
Was nach dem MVP kommt
Das Abnahmekriterium ist ein Satz: Fertig ist das MVP, wenn ein echter Nutzer den Ablauf im Produktivsystem ohne Hilfe zu Ende bringt. Nicht die abgearbeitete Funktionsliste, nicht die Freigabe im Projektteam, nicht der erfolgreiche Durchlauf in der Testumgebung.
Danach entscheidet die Beobachtung, nicht die alte Liste. Die zweite Stufe zieht sich die Punkte aus Ihrer Wunschliste, die durch den Betrieb bestätigt wurden — und in der Praxis sind das meist drei: die zweite Nutzergruppe mit der Übergabe zwischen beiden, das Rechtemodell, und die Schnittstelle, die den täglichen Export ersetzt. Erst dann lohnen Mandantentrennung, Auswertungen und Selbstbedienung. Dass der Aufwand dabei nicht linear mit dem Funktionsumfang wächst, sondern an Rechtemodell und Schnittstellen hängt, steht in Software entwickeln lassen: was das kostet.
Wie wir solche Anwendungen schneiden, bauen und betreiben — vom MVP bis zum laufenden Produkt: SaaS- und Software-Entwicklung.
Quellen
- Verordnung (EU) 2016/679 (DSGVO), deutscher Volltext aus dem Cellar-Dienst des Amts für Veröffentlichungen der EU, CELEX 32016R0679 — Artikel 13, 15, 17, 25, 30 Absatz 5, 32 Absatz 1 und 33 Absatz 1. publications.europa.eu, abgerufen am 30. Oktober 2026.
- Barrierefreiheitsstärkungsgesetz (BFSG), § 1 Zweck und Anwendungsbereich, § 2 Nummer 17 und 26, § 3 Absatz 3. gesetze-im-internet.de, abgerufen am 30. Oktober 2026.
- OWASP Top 10:2025 — Platz 1 „Broken Access Control“, Platz 9 „Security Logging and Alerting Failures“. top10.owasp.org, abgerufen am 30. Oktober 2026.
- SyncDev, „Minimum Viable Product“ — erste Verwendung des Begriffs 2001 und die Definition über „return on risk“. Die heutige Fassung der Adresse trägt diese Angaben nicht mehr, zitiert ist daher die Archivfassung derselben Adresse vom 29. Dezember 2015. web.archive.org, abgerufen am 30. Oktober 2026.
Häufige Fragen
Was kostet ein MVP?
Es gibt keinen Listenpreis, weil Aufwand bezahlt wird und nicht die Zahl der Funktionen. Beim MVP hängt der Aufwand an drei Größen: wie viele Nutzergruppen beteiligt sind, wie fein das Rechtemodell sein soll und wie viele Fremdsysteme angebunden werden müssen. Genau an diesen drei Stellen setzt der Schnitt an, den dieser Beitrag beschreibt — eine Nutzergruppe, eine Rolle, ein Export statt einer Schnittstelle. Wie sich ein Softwarepreis überhaupt zusammensetzt und woran Sie ein schwaches Angebot erkennen, steht in unserem Beitrag zu den Kosten von Individualsoftware.
Reichen acht Wochen für ein MVP?
Die Frage ist falsch gestellt, und das ist der Nutzen eines festen Rahmens. Acht Wochen sind in diesem Beitrag ein gesetzter Wert, keine erhobene Dauer: Es gibt keine belastbare Erhebung, die sagt, wie lange ein MVP „üblicherweise“ braucht, weil der Umfang von Fall zu Fall völlig verschieden ist. Sobald der Rahmen aber feststeht, lautet die Frage nicht mehr „wie lange braucht mein Umfang“, sondern „welcher Umfang passt in diesen Rahmen“ — und das ist eine Frage, die Sie beantworten können. Wählen Sie statt acht Wochen zwölf, verschiebt sich nur die Grenze, nicht das Verfahren.
Was ist der Unterschied zwischen Prototyp und MVP?
Ein Prototyp beantwortet die Frage, ob jemand das überhaupt so bedienen will. Er darf wegwerfbar sein, mit erfundenen Daten laufen und niemandem gehören. Ein MVP ist ein Produktivsystem: Es verarbeitet echte Daten echter Menschen, und damit gelten ab dem ersten echten Nutzer dieselben Pflichten wie für eine fertige Anwendung — Informationspflicht, Sicherheit der Verarbeitung, Sicherung mit geprüftem Rückweg, Meldewege bei einer Datenschutzverletzung. Entscheiden Sie das bewusst am Anfang. Der teuerste Weg ist der Prototyp, der still zum Produktivsystem wird, weil er einmal „nur kurz“ mit echten Daten befüllt wurde.
Welche Rechtspflichten gelten schon im MVP?
Sobald die erste echte Person das System benutzt, gelten die Datenschutzpflichten vollständig: Information bei der Erhebung (Artikel 13 DSGVO), angemessene technische und organisatorische Maßnahmen samt der Fähigkeit, Daten nach einem Zwischenfall rasch wiederherzustellen (Artikel 32), Datenschutz durch Technikgestaltung (Artikel 25), das Verzeichnis der Verarbeitungstätigkeiten (Artikel 30) und die Meldung einer Datenschutzverletzung binnen 72 Stunden (Artikel 33). Barrierefreiheit nach dem BFSG trifft Sie nur, wenn Ihr MVP eine Dienstleistung im elektronischen Geschäftsverkehr für Verbraucher ist; für reine B2B- oder interne Anwendungen gilt das Gesetz nicht. Erzeugt Ihr MVP KI-Ausgaben, kommt die Kennzeichnungspflicht nach Artikel 50 der KI-Verordnung dazu.
Wann ist ein MVP fertig?
Nicht, wenn die Funktionsliste abgearbeitet ist, sondern wenn ein echter Nutzer den einen Arbeitsablauf im Produktivsystem mit echten Daten ohne Hilfe zu Ende bringt. Dieses Kriterium ist absichtlich hart: Es schließt die Abnahme in der Testumgebung aus, die Abnahme mit Beispieldaten und die Abnahme, bei der jemand aus dem Projektteam über die Schulter schaut. Legen Sie es vor dem Start schriftlich fest, zusammen mit der Frage, wer dieser erste echte Nutzer ist.