Wie lange dauert die Entwicklung eines MVP? Ein fokussiertes Web-MVP braucht 3 bis 5 Wochen, wenn es einen Workflow mit Standard-Auth, einem Datenmodell und einer Erfolgskennzahl testet. Enthält das Briefing mehrere Rollen, komplexe Integrationen oder Freigabeschleifen, sind 6 bis 12 Wochen oder mehr realistisch.
Der unbequeme Teil: Der Kalender ist meistens eine Scope-Entscheidung, kein technisches Faktum.
Wer gerade Angebote vergleicht, wundert sich zu Recht über die große Spanne. Manche Teams kalkulieren einen ersten Test, andere eine abgespeckte Version des Endprodukts. Dieser Artikel zeigt den Zeitplan, den webvise einsetzt, die typischen Verzögerungsquellen und die Kürzungsregeln, die verhindern, dass ein MVP heimlich zum Vollprodukt wird.
- 3 bis 5 Wochen sind für einen Kernworkflow realistisch. Das bedeutet: eine primäre Nutzerrolle, eine Aufgabe, ein Datenbankschema, eine Launch-Kennzahl und schnelle Entscheidungen.
- 6 bis 12 Wochen sind normal, sobald mehrere Rollen oder tiefe Integrationen ins Spiel kommen. Das ist kein Scheitern, sondern ein größeres erstes Release.
- Die erste Woche entscheidet über den Gesamtplan. Fehlende Zugangsdaten, vage Abnahmekriterien und ungeklärte API-Fragen kosten mehr Zeit als der Code selbst.
- webvise schneidet MVP-Builds auf ein zentrales Lernziel zu und liefert fokussierte erste Releases in 3 bis 5 Wochen auf Next.js, PostgreSQL und Vercel, mit Auth, Payments und einer investorenfähigen Demo-Umgebung, wo das Sinn ergibt. Service-Details ansehen.
- Das sicherste MVP ist das kleinste Produkt, das innerhalb von 30 Tagen nach Launch eine Entscheidung ermöglicht.
Die kurze Antwort nach Scope-Typ
Öffentliche MVP-Zeitpläne landen meist zwischen 4 und 12 Wochen. Diese Spanne verdeckt die eigentlich relevante Frage: Um welche Art von MVP geht es?
Die Antwort hängt vom Scope-Typ ab. Das 3-bis-5-Wochen-Versprechen gilt für ein Web-MVP mit einem klaren Workflow, einem festgelegten Tech-Stack und einer Entscheidungsperson, die während des Builds Features streichen kann.
| Scope-Typ | Typischer Zeitrahmen | Was er beweist |
|---|---|---|
| Klickbarer Prototyp | 2 bis 5 Tage | Versteht jemand das Angebot und den Ablauf? |
| No-Code-Test | 1 bis 2 Wochen | Klicken, registrieren oder kaufen Nutzer, bevor Software existiert? |
| Fokussiertes Web-MVP | 3 bis 5 Wochen | Kann ein Nutzer den Kernworkflow mit echten Daten abschließen? |
| Standard-Produkt-MVP | 6 bis 12 Wochen | Können mehrere Rollen das Produkt mit echten Integrationen nutzen? |
| Reguliertes oder Marktplatz-MVP | 12+ Wochen | Kann das Produkt Risiken, Berechtigungen, Compliance oder zweiseitige Nachfrage bewältigen? |
Wer zuerst eine Landing Page, eine Warteliste und manuelles Follow-up braucht, sollte noch kein MVP beauftragen. Wer Auth, einen Workflow, eine Datenbank, Deployment und Analytics benötigt, passt in die webvise MVP-Entwicklung.
Der Wochenplan im Detail
Ein 3-bis-5-Wochen-MVP funktioniert, wenn riskante Entscheidungen vor dem Kickoff getroffen sind und das erste Release schmal genug ist, um schnell getestet zu werden.
| Phase | Was passiert | Entscheidung erforderlich |
|---|---|---|
| Vor dem Kickoff | Lernziel, Nutzer, Workflow, Launch-Kennzahl, Zugänge und harte Cuts werden festgelegt | Eine Person akzeptiert die Scope-Grenzen |
| Woche 1 | UX-Flow, Datenmodell, Auth, Deployment und erster klickbarer Pfad | Keine neue Nutzerrolle ohne Streichung einer anderen |
| Woche 2 | Kernworkflow, Datenbankschreibvorgänge, E-Mail- oder Zahlungspfad, grundlegender Admin-Bedarf | Integrationen bleiben standard, solange sie den Workflow nicht beweisen müssen |
| Woche 3 | Echte Daten, Analytics, Fehlerbehandlung, Mobile-Checks, erster interner Test | Nur Bugs und Launch-Blocker kommen in den Scope |
| Woche 4 | Nutzerseitige Feinarbeit, Texte, Übergabe, Tracking, Produktions-Deployment | Launch schlägt eine weitere Runde Präferenzanpassungen |
| Woche 5 | Puffer für Feedback, Sonderfälle bei Zahlungen, Partner-API-Probleme oder Datenbereinigung | Was nicht zum Launch gehört, kommt nach dem Release |
Der Stack ist nicht das Geheimnis. Für dieses Tier kommen Next.js, React, TypeScript, PostgreSQL, Drizzle ORM, Vercel und grundlegendes Analytics zum Einsatz. Die Geschwindigkeit entsteht durch bekannte Bausteine und die konsequente Weigerung, Infrastruktur zu erfinden, bevor das Produkt Belege hat.
Was aus 3 Wochen 3 Monate macht
Die meisten MVP-Verzögerungen haben keinen technischen Ursprung. Sie entstehen durch Entscheidungen, die offen gelassen wurden, weil niemand Nice-to-have-Features streichen wollte.
| Verzögerungsquelle | Wie es klingt | Wie der Zeitplan bleibt |
|---|---|---|
| Nutzerrollen | "Admin, Käufer, Verkäufer, Partner und Support brauchen alle Dashboards" | Eine primäre Nutzerrolle und einen internen Operator wählen |
| Integrationen | "CRM, Billing, Analytics, Slack und die alte Datenbank müssen ab Tag eins laufen" | Nur das System behalten, das den Workflow beweist |
| Freigabeschleifen | "Das Team schaut drüber, wenn alle Zeit haben" | Eine Entscheidungsperson mit 24-Stunden-Antwortzeit benennen |
| Design-Scope | "Erst alle Screens in Figma fertig, dann Build" | Den Kernpfad zuerst designen, Feinarbeit nach dem Funktionstest |
| Compliance-Annahmen | "Audit-Logs könnten später nötig sein" | Nur die rechtlich und sicherheitstechnisch notwendigen Checks für erste Nutzer bauen |
Deshalb zählt ein knappes MVP-Briefing mehr als eine lange Feature-Liste. Das Template aus dem MVP-Requirements-Guide ist das Format, das vor einem eingegrenzten Build vorliegen sollte.
Fallbeispiel: Der Scope hatte seinen Grund
Bei einem Immobilien-MVP war die Deadline nicht willkürlich. Das Produktversprechen war konkret: Ein Käufer sollte eine verbindliche Finanzierungsbestätigung erhalten, ohne dass eine Schufa-Abfrage stattfindet, während das System im Hintergrund Partnerbank-Angebote verglich. So ein Produkt kann sich schnell bewegen, wenn die erste Version einen Workflow schützt statt eine vollständige Finanzplattform nachzubauen.
Ein kleines MVP war das nicht, und es so zu nennen wäre unehrlich gewesen. Das erste Release brauchte einen vollständigen Finanzierungsworkflow, automatische PDF-Zertifikatsgenerierung und ein Admin-Dashboard für den Anfrage-Lifecycle.
Das Ergebnis blieb trotzdem schlank: fokussierter Build, starke Lighthouse-Performance, schnelle Ladezeiten und Zertifikatrücklauf im zugesagten Servicefenster. Den Zeitplan verlängerten echte Finanzdaten und eine echte Betriebsübergabe, keine dekorativen Features.
Fallbeispiel: Vibe-coded MVPs sparen Tage und kosten Wochen
Am 2026-05-18 erschien ein Artikel über Lovable, Bolt und v0 als MVP-Basis. Diese Tools sind für Prototypen nützlich, weil sie eine Gründeridee in Stunden sichtbar machen. Das Problem beginnt, wenn ein Prototyp als Produktfundament behandelt wird.
Das Muster ist konsistent genug, dass daraus eine Regel wurde: Sobald eine vibe-coded App echte Nutzer hat, wird sie neu gebaut statt gepatcht. Ein sauberer Build auf bewährtem Stack dauert typischerweise 3 bis 6 Wochen. Sanierungsarbeit kann 8 bis 12 Wochen kosten, weil jede Änderung ein Schema, eine Routenstruktur und ein Live-Datenmodell respektieren muss, das nie bewusst entworfen wurde.
Die weniger glamouröse Antwort ist die budgetfreundlichere: AI-App-Builder zeigen, was das Produkt können soll. Ein MVP-Build liefert dann verlässliche Daten von echten Nutzern.
Der 30-Minuten-Scope-Test
Bevor Sie eine Agentur nach einem Zeitplan fragen, sollten Sie Ihren Scope durch diesen Test führen. Wer die Antworten nicht in 30 Minuten hat, ist noch nicht bereit für einen festen Kalender.
- Ein Satz: Welche riskante Annahme muss Version eins beweisen?
- Ein Nutzer: Wer nutzt das erste Release vor allen anderen?
- Ein Workflow: Welche Schritte bringen diesen Nutzer vom Einstieg zum Mehrwert?
- Eine Kennzahl: Welche Zahl zeigt innerhalb von 30 Tagen, ob es weitergeht?
- Eine Entscheidungsperson: Wer kann Scope innerhalb von 24 Stunden streichen oder akzeptieren?
- Zugänge: Welche Auth-, Payment-, E-Mail-, Analytics-, Hosting- und Datenbank-Accounts stehen bereit?
- Harte Cuts: Was wird vor dem Launch nicht geliefert, egal ob jemand es fordert?
Passen die Antworten auf eine Seite, ist ein 3-bis-5-Wochen-MVP realistisch. Brauchen sie einen Workshop, beginnt die Arbeit mit dem Briefing. Die Kostenperspektive zur gleichen Entscheidung findet sich im MVP-Kostenguide.
Wann ein längerer Build die ehrliche Antwort ist
Manche ersten Releases sollten nicht in 5 Wochen gepresst werden. Regulierte Daten, medizinische Aussagen, Finanzentscheidungen, Marktplätze, Mobile-App-Stores und komplexe Partner-APIs können einen längeren Build rechtfertigen.
Die Prüffrage ist einfach: Schützt die zusätzliche Zeit einen echten Nutzer, eine echte Transaktion oder eine echte rechtliche Pflicht? Dann bleibt sie. Macht sie das Produkt nur vollständiger, wird sie gestrichen.
webvise hilft Gründern, diese Einschätzung zu treffen, bevor Code entsteht. Ist das MVP schmal genug für 3 bis 5 Wochen, ist der MVP-Development-Service die richtige Wahl. Ist es bereits eine Produktionsplattform, wird das ehrlich gesagt und anders eingeplant.
Ein guter MVP-Zeitplan entsteht aus klarem Scope, schnellen Entscheidungen und einer ersten Version, die genau eine Geschäftsfrage beantwortet. Wer möchte, dass webvise das Briefing unter Druck testet, bevor gebaut wird: Jetzt schicken.