MVP-Start: was vor der ersten zahlenden Kundin stehen muss
Für: Gründerinnen und Produktverantwortliche
Aktualisiert: 2026-09
Vor dem Start eines MVP müssen fünf Dinge stehen: eine funktionierende Zahlungsstrecke, eine Datenlage, die spätere Änderungen erlaubt, ein Weg zur Löschung von Konten, eine Möglichkeit zu erfahren wenn etwas kaputt ist, und rechtliche Grunddokumente. Alles andere kann warten.
Die schwierigste Frage vor einem MVP-Start ist nicht, was gebaut werden muss, sondern was ausdrücklich nicht. Jede zusätzliche Funktion verzögert den Zeitpunkt, an dem man erfährt, ob überhaupt jemand zahlt — und genau diese Erkenntnis ist der Zweck der Übung.
Diese Liste trennt beides. Sie enthält bewusst nur Punkte, deren Fehlen entweder den Start unmöglich macht oder später unverhältnismässig teuer zu korrigieren ist.
Die Checkliste
- 01
Zahlungsstrecke vollständig durchspielen
Registrierung, Abonnement, Zahlungsfehler, Kündigung und Rückerstattung mindestens einmal echt durchlaufen. Fehler in diesem Ablauf kosten unmittelbar Umsatz und Vertrauen.
Erledigt, wenn: Alle fünf Fälle wurden mit einer echten Zahlung getestet, einschliesslich einer fehlgeschlagenen Zahlung.
- 02
Datenmodell auf Änderbarkeit prüfen
Das Datenmodell ist die teuerste Entscheidung im Produkt. Prüfen Sie, ob sich Mandantenfähigkeit, Nutzerrollen und Abrechnungseinheiten später ändern lassen, ohne alles neu zu schreiben.
Erledigt, wenn: Für die drei wahrscheinlichsten Modelländerungen ist der Weg dorthin grob beschrieben.
- 03
Kontolöschung umsetzen
Nutzerinnen müssen ihr Konto und ihre Daten löschen können. Das ist rechtlich erforderlich und lässt sich nachträglich nur mühsam einbauen, wenn es beim Datenmodell nicht mitgedacht wurde.
Erledigt, wenn: Eine Kontolöschung wurde durchgeführt und danach überprüft, dass keine personenbezogenen Daten zurückbleiben.
- 04
Rechtliche Grunddokumente bereitstellen
Impressum, Datenschutzerklärung und Nutzungsbedingungen, die das tatsächliche Produkt beschreiben. Eine übernommene Vorlage, die nicht zum Produkt passt, ist schlechter als keine.
Erledigt, wenn: Die Datenschutzerklärung nennt alle tatsächlich eingesetzten Drittdienste namentlich.
- 05
Erfahren, wenn etwas kaputt ist
Fehlererfassung und eine Benachrichtigung bei Ausfall. Ohne das erfahren Sie von Problemen durch abwandernde Nutzerinnen — also zu spät und ohne Details.
Erledigt, wenn: Ein absichtlich ausgelöster Fehler ist innerhalb weniger Minuten in der Benachrichtigung angekommen.
- 06
Sicherung und Wiederherstellung testen
Nicht nur einrichten, sondern einmal wiederherstellen. Bei einem jungen Produkt ist Datenverlust der einzige Fehler, von dem man sich praktisch nicht erholt.
Erledigt, wenn: Eine Wiederherstellung wurde durchgeführt, und die dafür benötigte Zeit ist bekannt.
- 07
Einen Weg für Rückmeldungen schaffen
Eine sichtbare Möglichkeit, Sie zu erreichen. Die ersten Nutzerinnen sind die wertvollste Informationsquelle, die ein Produkt je hat — der Zugang dazu sollte nicht verstellt sein.
Erledigt, wenn: Ein Kontaktweg ist im Produkt sichtbar, und eingehende Nachrichten kommen nachweislich an.
Häufige Fehler
- —Der Start wird für Funktionen verschoben, die niemand angefragt hat. Der eigentliche Zweck des MVP — herauszufinden, ob jemand zahlt — verschiebt sich damit ebenfalls.
- —Die Zahlungsstrecke wird nur im Testmodus geprüft. Echte Zahlungen verhalten sich in Randfällen anders, besonders bei Fehlschlägen und Rückerstattungen.
- —Die Kontolöschung wird auf später verschoben. Wenn das Datenmodell sie nicht vorsieht, wird sie zur grösseren Umbaumassnahme.
- —Die Datenschutzerklärung ist eine Vorlage, die Dienste nennt, die gar nicht eingesetzt werden — oder die eingesetzten verschweigt.
Was diese Checkliste nicht abdeckt
- —Diese Liste behandelt die Startfähigkeit, nicht die Produktqualität. Ob das Produkt einen Markt hat, beantwortet sie nicht.
- —Sicherheit ist hier nur mit den Grundlagen vertreten. Bei sensiblen Daten oder regulierten Branchen ist eine eigene Prüfung nötig.
- —Bei KI-Funktionen im Produkt kommen Einordnung und Transparenzpflichten nach dem AI Act hinzu, die hier nicht behandelt werden.
- —Marketing, Preisgestaltung und Vertrieb sind bewusst ausgeklammert.
Übergeordnete Leistung: SaaS-Produktentwicklung
Passende Angebote
Festpreis-MVP-Entwicklung
Eine Festpreis-MVP-Entwicklung liefert ein klar abgegrenztes, lauffähiges Produkt zu einem vorab definierten Preis — auf einem modernen, EU-gehosteten Stack. Kein offenes Stunden-Fass, sondern ein definierter Umfang mit klarem Ergebnis.
SaaS-Launch-Paket
Das Launch-Paket bringt ein SaaS-Produkt von der Idee zum Markt: tragfähige Architektur, die entscheidenden Kern-Funktionen, Billing, Onboarding und Deployment — geführt und mit klarem Fokus auf den ersten zahlenden Kunden. Ergebnis ist kein Prototyp, sondern ein produktionsreifes Produkt, das Umsatz erzeugen kann.
Häufige Fragen
Was kann getrost warten?
Feingranulare Rollen und Rechte, Mehrsprachigkeit, ausgefeilte Einstellungsseiten, eine öffentliche Schnittstelle und die meisten Integrationen. Diese lassen sich nachrüsten, ohne das Fundament anzufassen.
Braucht ein MVP schon ein Verarbeitungsverzeichnis?
Sobald personenbezogene Daten verarbeitet werden, ja. Der Aufwand ist zu Beginn klein und wächst mit jedem Monat, in dem er aufgeschoben wird.
Wie lange sollte ein MVP brauchen?
Kürzer, als die meisten planen. Die entscheidende Grösse ist nicht die Dauer, sondern wie schnell die erste echte Zahlung eingeht — daran misst sich, ob die Annahme trägt.
Weitere Checklisten
Cloud-Migration vorbereiten: die Fragen vor dem ersten Verschieben
Eine Cloud-Migration scheitert selten an der Technik, sondern an mangelnder Vorbereitung: unbekannte Abhängigkeiten, ungeklärte Datenklassifizierung, ein Kostenmodell das erst nach dem Umzug sichtbar wird, und fehlende Abnahmekriterien, an denen sich Erfolg überhaupt messen liesse.
Altsystem ablösen: die Vorarbeit, die über den Ausgang entscheidet
Die Ablösung eines Altsystems scheitert meist an drei Dingen: undokumentierter Fachlogik, die niemand mehr kennt, Datenqualität die erst bei der Migration sichtbar wird, und einem fehlenden Abschaltzeitpunkt, wodurch beide Systeme dauerhaft parallel laufen.
Softwarepartner auswählen: was vor der Beauftragung zu prüfen ist
Bei der Auswahl eines Softwarepartners entscheiden weniger die Referenzen als vier vertragliche Punkte: Wem gehört das Ergebnis, wer hat Zugang zu den Systemen, wie sieht eine Übergabe aus, und was passiert, wenn die Zusammenarbeit endet.