Ein MVP-Anforderungsdokument sollte festhalten, was die erste Version beweisen muss, nicht alles, was das Produkt eines Tages werden könnte. webvise behandelt es als Lernvertrag: ein Nutzertyp, ein Workflow, eine Erfolgsmetrik und eine klare Liste dessen, was außerhalb des Scopes liegt.
Liest sich Ihr Dokument wie ein Feature-Backlog, ist Ihr MVP bereits zu groß geraten.
Gründer kennen ihr Produkt meist besser als der Entwickler, briefen aber häufig das falsche Artefakt. Diese Anleitung liefert die Vorlage, die vor einem fokussierten MVP-Build gebraucht wird, samt Beispielen und Schnittentscheidungen, die einen 3- bis 5-wöchigen Build vor einer quartallangen Überarbeitung bewahren.
- Das Dokument kauft Erkenntnisse, keine Vollständigkeit. Hilft ein Feld nicht dabei, die kommerzielle Annahme zu beweisen, fliegt es raus.
- Ein Workflow reicht für Version eins. Mehr Workflows bedeuten mehr Zustände, mehr Tests und einen langsameren Launch.
- Die Out-of-Scope-Liste schützt das Budget. Ein Feature gilt erst dann als gestrichen, wenn alle sehen können, wo es geblieben ist.
- Der Entwickler braucht Entscheidungen, keine Abhandlungen. Nutzertyp, Auslöser, Daten, Verantwortliche und Launch-Metrik müssen konkret benannt sein.
- Ein gutes MVP-Brief passt auf zwei Seiten. Die eigentliche Arbeit besteht darin, zu entscheiden, was nicht hineinkommt.
Das Dokument ist ein Lernvertrag
Ein normales PRD beschreibt ein Produkt. Ein MVP-Anforderungsdokument beschreibt einen Test. Die erste Zeile muss die riskante Annahme benennen, die das Produkt überhaupt erst bauwürdig macht.
Dieser Unterschied verändert den Scope grundlegend. Produktdokumente sammeln Möglichkeiten; ein MVP-Dokument erzwingt ein klares Ja oder Nein dazu, was echte Nutzer tun müssen, bevor die nächste Investition Sinn ergibt.
webvise scopiert MVP-Builds rund um das erste Lernziel. Braucht die erste Version Auth, einen zentralen Workflow, eine Datenbank, Deployment und Analytics, passt das in einen 3- bis 5-wöchigen Build. Fünf Nutzerrollen und drei Dashboards gehören meist in eine spätere Phase, nachdem der erste Test den Weg validiert hat.
Diese MVP-Anforderungsdokument-Vorlage zum Kopieren
Nutzen Sie das als zweiseitiges Brief, bevor Sie ein Angebot anfragen. Je präziser die Antworten, desto leichter kann ein erfahrener Entwickler die Arbeit bepreisen, ohne den Schätzaufschlag für Unklarheiten einzukalkulieren.
| Abschnitt | Was hineingehört | Bestanden, wenn |
|---|---|---|
| Riskante Annahme | Die kommerzielle Überzeugung, die diese Version beweisen muss | Wäre sie falsch, würden Sie das Produkt ändern oder stoppen |
| Primärer Nutzer | Ein konkreter Nutzertyp, kein Marktsegment | Der Entwickler kann sich die Person beim Nutzen vorstellen |
| Kern-Workflow | Die Schritte von der ersten Aktion bis zum Mehrwert | Auch ein Fremder kann den Workflow testen |
| Erfolgsmetrik | Eine einzige Zahl, die entscheidet, ob Version eins funktioniert hat | Die Metrik ist innerhalb von 30 Tagen nach Launch messbar |
| Out of Scope | Features, die verlockend sind, aber ausgeschlossen werden | Alle Stakeholder können auf dieselben Streichungen zeigen |
| Daten und Integrationen | Systeme, Dateien, APIs, Zahlungen, E-Mail, Auth | Keine versteckte Abhängigkeit taucht in Bauphase zwei auf |
| Launch-Constraint | Budget, Zeitplan, rechtliche Vorgaben, Gerät, Browser, Sprache | Der Constraint kann Scope blockieren, bevor Code geschrieben wird |
| Entscheidungsverantwortliche | Die Person, die Streichungen akzeptieren darf | Der Entwickler muss keine internen Debatten moderieren |
Unsicherheiten gehören offengelegt. Steht die Metrik noch nicht fest, nennen Sie den nächstbesten Proxy und markieren ihn als vorläufig. Eine fehlende Entscheidung im Dokument wird zum Meeting während des Builds.
- Arbeitstitel: ein Satz, der sagt, was das Produkt tut.
- Primärer Nutzer: der erste Nutzer, den Sie ansprechen, nicht alle denkbaren Käufer.
- Kern-Workflow: 5 bis 10 Schritte vom Einstieg bis zum Mehrwert.
- Launch-Metrik: die Zahl, die sich in den ersten 30 Tagen messen lässt.
- Erforderliche Systeme: Stripe, Resend, CRM, Tabellenkalkulation, CMS oder internes API.
- Out-of-Scope-Liste: alle Features, die bewusst jetzt nicht gebaut werden.
- Abnahmeregel: wer zeichnet ab, wenn der Build dem Brief entspricht.
Wer einen Build-Partner sucht, der dieses Dokument vor dem ersten Code herausfordert: der MVP-Development-Service von webvise umfasst Product Scoping, Feature-Priorisierung, UI-Design, Full-Stack-Entwicklung, Deployment und grundlegendes Analytics.
Features mit dem Fünf-Fragen-Gate herausfiltern
Die meisten Scope-Konflikte entstehen, weil jedes Feature für sich genommen vernünftig klingt. Das Gate beendet das. Ein Feature bleibt nur im MVP, wenn es alle fünf Fragen besteht.
| Frage | Drinbehalten, wenn | Streichen, wenn |
|---|---|---|
| Beweist es die riskante Annahme? | Die Antwort verändert die nächste Finanzierungs-, Vertriebs- oder Bauentscheidung | Es macht das Produkt nur vollständiger |
| Braucht der erste Nutzer es? | Der primäre Nutzer kann den Mehrwert ohne es nicht erreichen | Ein späterer Nutzertyp würde es schätzen |
| Lässt es sich in 30 Tagen messen? | Nutzungs-, Zahlungs-, Abschluss- oder Antwortdaten zeigen sich schnell | Das Signal braucht eine große Zielgruppe, die noch nicht vorhanden ist |
| Reduziert es operatives Risiko? | Es verhindert Betrug, Datenverlust, Support-Ausfall oder rechtliche Haftung | Es existiert, weil ein Wettbewerber es hat |
| Lässt es sich für Version eins manuell erledigen? | Manuelle Arbeit würde das Versprechen brechen oder unsichere Datenprozesse erzeugen | Manuelle Arbeit ist lästig, aber für die ersten zehn Nutzer akzeptabel |
Die Frage nach manueller Arbeit spart echtes Geld. Viele Gründer bauen Admin-Screens, Abrechnungs-Edge-Cases und Notification-Center, bevor sie wissen, ob irgendjemand das Produkt ein zweites Mal nutzen wird.
Mini-Story: Ein Output zählte
Ein Immobilien-MVP startete nicht als generische Fintech-Plattform. Ausgangspunkt war ein einziger Output: Ein Käufer muss ein verbindliches Finanzierungszertifikat erhalten, ohne dass eine Schufa-Anfrage ausgelöst wird, während das System im Hintergrund Partnerbank-Optionen vergleicht. Dieser Output hat den Scope stärker geformt als jede Feature-Wunschliste.
Gebaut wurde der Finanzierungs-Workflow, eine automatisierte PDF-Zertifikatsgenerierung und ein Admin-Dashboard zur Steuerung des Antragslebenszyklus. Der Build basierte auf dem bewährten Production-Stack: Next.js, React, tRPC, TypeScript, PostgreSQL, Drizzle ORM, Tailwind CSS und Vercel.
| Scope-Entscheidung | Anonymisiertes Beispiel | Warum es blieb |
|---|---|---|
| Primärer Nutzer | Immobilienkäufer | Der Zertifikats-Workflow startet mit diesem Nutzer |
| Kern-Workflow | Mehrstufiges Finanzierungsformular | Es erfasst die Daten, die für ein gültiges Zertifikat benötigt werden |
| Erfolgsoutput | Zertifikat innerhalb der zugesagten Bearbeitungszeit | Das Geschäftsversprechen hängt an der Bearbeitungszeit |
| Datenabhängigkeit | Partnerbank-Vergleich | Das Produkt kann das Versprechen ohne den Vergleich nicht einhalten |
| Admin-Bedarf | Dashboard für den Antragslebenszyklus | Das Team brauchte Kontrolle nach dem Eingang |
| Performance-Anforderung | Schneller mobiler Ladevorgang und starker Lighthouse-Score | Der Funnel musste vertrauenswürdig wirken, bevor sensible Daten eingegeben werden |
Ein scharf umrissener Output lässt einen langen Workflow kleiner erscheinen als eine Handvoll vager Features.
Mini-Story: Vibe-Coded MVPs scheitern beim Handoff
Lovable, Bolt und v0 eignen sich für Prototypen, weil sie die Zeit zwischen Idee und öffentlicher URL stark verkürzen. Das Problem beginnt, wenn dieser Prototyp zum MVP umbenannt wird und zahlende Kunden bekommt, bevor irgendjemand Auth, Datenzugriff, Admin-Workflows oder Observability verantwortet.
Im Vibe-Coded-MVP-Teardown steht die Regel für Gründer, die solche Codebasen mitbringen: Neubau von Grund auf. Ein sauberer Build auf dem bewährten Stack dauert 3 bis 6 Wochen. Salvage dauert 8 bis 12 Wochen, weil jede Änderung ein Schema, eine Routenstruktur und ein Live-Datenmodell respektieren muss, das nie bewusst entworfen wurde.
Deshalb muss das Anforderungsdokument die Handoff-Oberfläche einschließen. Zahlt ein Kunde, braucht das MVP vom ersten Tag an ein echtes Datenmodell, Session-Regeln, Admin-Aktionen und Monitoring. Steht im Dokument nur Login, Dashboard und AI-Feature, füllt der Entwickler die riskantesten Stellen ohne Ihre Vorgaben.
So übergeben Sie das Dokument an eine Agentur
Schicken Sie das Dokument vor dem ersten Kostenvoranschlag und beurteilen Sie die Agentur an den Fragen, die sie stellt. Ein guter Entwickler kürzt, hinterfragt und sequenziert den Scope. Ein schwacher akzeptiert jedes Feature und versteckt die Kosten in einem größeren Angebot.
- Budgetrahmen: nennen Sie, ob es sich um eine 5.000-€-, 15.000-€- oder 50.000-€-Entscheidung handelt, bevor der Scope wächst.
- Zeitplan: benennen Sie das Launch-Datum und den Grund, warum es zählt.
- Bestehende Nachweise: fügen Sie Wartelisten-Zahlen, Interviews, Prototyp-Links, bezahlte Absichtserklärungen oder manuelle Workflow-Daten bei.
- Erforderliche Accounts: listen Sie Stripe, Vercel, Supabase, PostHog, CRM, E-Mail und Domain-Zugang vor dem Kickoff auf.
- Hard-No-Liste: halten Sie fest, was nicht passieren darf, etwa das Speichern von Gesundheitsdaten, ein No-Code-Backend oder ein Launch ohne Audit-Logs.
- Streichungsverantwortliche: benennen Sie die Person, die ein Feature innerhalb von 24 Stunden entfernen kann.
Zur Orientierung: webvise baut MVPs mit Next.js, React, TypeScript, PostgreSQL, Drizzle ORM, Vercel, CI/CD, Analytics und Deployment als fester Bestandteil des initialen Scopes. Der Stack verfolgt ein Ziel: ein MVP, das sauber genug ist, um zu wachsen, sobald der Test funktioniert.
Der finale Test vor dem Versenden
Lesen Sie jede Zeile und fragen Sie, ob sie dem Entwickler hilft, eine Scope-Entscheidung zu treffen. Verändert sie nichts daran, was gebaut, gemessen, gestrichen oder verschoben wird, gehört sie raus.
| Schwache Formulierung | Neu formuliert als | Warum es funktioniert |
|---|---|---|
| Nutzer können ihr Profil verwalten | Käufer können Name, E-Mail, Telefon und Finanzierungsbetrag vor der Zertifikatsgenerierung bearbeiten | Nennt Nutzertyp, Felder und Workflow |
| Admin-Dashboard | Mitarbeiter können neue Zertifikatsanfragen einsehen, den Status ändern und das generierte PDF herunterladen | Beschreibt die tatsächliche Admin-Aufgabe |
| KI-Empfehlungen | Das System meldet fehlende Finanzierungsdaten vor dem Absenden zunächst auf Basis fester Validierungsregeln | Vermeidet vagen KI-Scope, bis die Regel bekannt ist |
| Zahlungen später | Stripe ist für Version eins außerhalb des Scopes, sofern kein bezahltes Pilot-Agreement vor Kickoff unterzeichnet wird | Macht aus einer Zukunftsidee einen konkreten Auslöser |
| Mobilfreundlich | Das Finanzierungsformular muss auf einem schmalen Smartphone bedienbar sein, bevor Desktop-Feinschliff erfolgt | Macht die Geräteanforderung testbar |
Ein kurzes MVP-Anforderungsdokument fühlt sich unangenehm an, weil es die echte Entscheidung sichtbar macht. Das ist der Punkt. Es soll offenlegen, worauf Sie wetten, was Sie bewusst nicht bauen und welches Ergebnis die nächste Version rechtfertigt.
webvise hilft Gründern, diese Entscheidung in eine ausgelieferte erste Version zu überführen statt in eine aufgeblähte Feature-Liste. Ist Ihr MVP-Brief nah dran, aber noch zu breit: Schicken Sie ihn an webvise und erfahren Sie genau, was vor der ersten Bau-Woche gestrichen werden würde.