Wie lange dauert die Entwicklung eines MVP? Ein praktischer Plan für 3 bis 5 Wochen
Ein fokussiertes MVP dauert 3 bis 5 Wochen, wenn es einen Workflow mit Standard-Auth, einem Datenmodell und einer Erfolgskennzahl testet. Hier ist der ehrliche Zeitplan.
Wie lange dauert die Entwicklung eines MVP? Ein fokussiertes Web-MVP dauert 3 bis 5 Wochen, wenn es einen Workflow mit Standard-Auth, einem Datenmodell und einer Erfolgskennzahl testet. Es dauert 6 bis 12 Wochen oder länger, wenn der Brief mehrere Rollen, schwere Integrationen oder Freigaben durch ein Gremium enthält.
Der unbequeme Teil: Der Kalender ist meistens eine Scope-Entscheidung, keine technische Tatsache.
Wenn Sie gerade Angebote vergleichen, ist die Spanne aus einem nachvollziehbaren Grund verwirrend. Manche Teams bieten einen ersten Test an, andere eine kleine Version des späteren Produkts. Dieser Guide zeigt den Zeitplan, den wir bei webvise verwenden, die Blocker, die ihn verlängern, und die Kürzungsregeln, die ein MVP davon abhalten, sich als vollständiger Build zu verkleiden.
3 bis 5 Wochen sind realistisch für einen Kernworkflow. Das bedeutet einen primären Nutzer, eine Aufgabe, eine Datenbankform, eine Launch-Kennzahl und schnelle Entscheidungen.
6 bis 12 Wochen sind normal, wenn der Scope mehrere Rollen oder tiefe Integrationen enthält. Das ist kein Scheitern. Es ist ein größerer erster Release.
Die erste Woche entscheidet den Zeitplan. Langsamer Account-Zugriff, vage Abnahmeregeln und späte API-Entscheidungen kosten mehr Zeit als Code.
webvise baut MVPs ab €5.000 in 3 bis 5 Wochen, wenn der Scope in diese Form passt. Die Leistungsbeschreibung steht hier: MVP Development.
Das sicherste MVP ist nicht die kleinste Feature-Menge. Es ist das kleinste Produkt, das innerhalb von 30 Tagen nach Launch eine Entscheidung erzeugen kann.
Die kurze Antwort nach Scope
Öffentliche MVP-Zeitplan-Guides landen meist zwischen 4 und 12 Wochen. Diese Spanne ist nicht falsch, aber sie verdeckt die nützliche Frage: Über welche Art MVP sprechen wir?
Bei webvise trennen wir die Antwort nach Scope-Form. Das Versprechen von 3 bis 5 Wochen gehört zu einem Web-MVP mit klarem Workflow, festem Tech-Stack und einem Entscheidungsinhaber, der während des Builds Features streichen kann.
| Scope-Form | Typischer Zeitplan | Was es beweist |
|---|---|---|
| Klickbarer Prototyp | 2 bis 5 Tage | Versteht jemand Angebot und Ablauf? |
| No-code Test | 1 bis 2 Wochen | Klicken, registrieren oder zahlen Menschen, 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 Marketplace-MVP | 12+ Wochen | Kann das Produkt Risiko, Rechte, Compliance oder zweiseitige Nachfrage tragen? |
Wenn Ihre Idee zuerst eine Landingpage, Warteliste und manuelle Nachverfolgung braucht, zahlen Sie noch nicht für ein MVP. Wenn sie Auth, einen Workflow, eine Datenbank, Deployment und Analytics braucht, passt sie in die Lane webvise MVP Development.
Die Version Woche für Woche
Ein MVP in 3 bis 5 Wochen ist kein zusammengedrücktes Vollprodukt. Es ist ein Build, bei dem die riskanten Entscheidungen vor dem Kickoff getroffen werden und der erste Release eng genug bleibt, um schnell zu testen.
| Phase | Was passiert | Benötigte Entscheidung |
|---|---|---|
| Vor dem Kickoff | Lernziel, Nutzer, Workflow, Launch-Kennzahl, Accounts und harte Kürzungen sind benannt | Ein Owner akzeptiert Scope-Grenzen |
| Woche 1 | UX-Flow, Datenmodell, Auth, Deployment und erster klickbarer Pfad | Keine neue Nutzerrolle, ohne etwas anderes zu entfernen |
| Woche 2 | Kernworkflow, Datenbank-Schreibvorgänge, E-Mail- oder Zahlungspfad, einfacher Admin-Bedarf | Integrationen bleiben Standard, außer sie beweisen das Produkt |
| Woche 3 | Echte Daten, Analytics, Fehlerbehandlung, Mobile-Checks, erster interner Test | Nur Defekte und Launch-Blocker kommen in den Scope |
| Woche 4 | Nutzerseitiger Feinschliff, Copy, Übergabe, Tracking, Produktionsdeploy | Launch schlägt eine weitere Runde Geschmacksänderungen |
| Woche 5 | Puffer für Feedback, Zahlungsfälle, Partner-API-Probleme oder Datenbereinigung | Alles ohne Launch-Bezug wandert nach dem Release |
Der Stack ist nicht der Trick. webvise baut diese Stufe meist mit Next.js, React, TypeScript, PostgreSQL, Drizzle ORM, Vercel und Basis-Analytics. Die Geschwindigkeit entsteht aus bekannten Bausteinen und der Weigerung, Infrastruktur zu erfinden, bevor das Produkt Evidenz hat.
Was aus 3 Wochen 3 Monate macht
Die meisten MVP-Verzögerungen entstehen nicht durch schwere Technik. Sie entstehen durch Entscheidungen, die weich gelassen wurden, weil niemand die Nice-to-have-Arbeit kürzen wollte.
| Verzögerungsquelle | Wie es klingt | Wie der Zeitplan hält |
|---|---|---|
| Nutzerrollen | 'Admin, Käufer, Verkäufer, Partner und Support brauchen alle Dashboards' | Einen primären Nutzer und einen internen Operator wählen |
| Integrationen | 'Wir brauchen CRM, Billing, Analytics, Slack und die alte Datenbank an Tag eins' | Nur das System behalten, das den Workflow beweist |
| Freigabeschleifen | 'Das Team prüft, wenn alle Zeit haben' | Einen Kürzungs-Owner mit 24-Stunden-Antwortzeit benennen |
| Design-Scope | 'Lassen Sie uns jeden Screen in Figma fertigstellen, bevor gebaut wird' | Den Kernpfad zuerst designen und nach Funktion polieren |
| Compliance-Claims | 'Vielleicht brauchen wir später Audit-Logs' | Nur die Rechts- und Sicherheitschecks bauen, die erste Nutzer brauchen |
Darum zählt ein kurzer MVP-Brief mehr als eine lange Feature-Liste. Die Vorlage in unserem Guide zum MVP Requirements Document ist die Version, die wir vor einem Festpreis-Build sehen wollen.
Mini-Story: OHYP brauchte aus den richtigen Gründen 6 Wochen
Am 2026-02-20 veröffentlichten wir die Case Study zu OHYP GmbH, einem Berliner Immobilienservice, der Finanzierungszertifikate für Käufer in Deutschland brauchte. Das Geschäftsversprechen war konkret: Ein Käufer sollte innerhalb von 24 Stunden ein verbindliches Zertifikat erhalten, ohne SCHUFA-Abfrage, während das System mehr als 550 Partnerbanken vergleicht.
Das war kein MVP für 3 Wochen, und es so zu nennen wäre unehrlich gewesen. Der erste Release brauchte ein Finanzierungsformular mit 10 Schritten, automatisierte PDF-Zertifikate und ein Admin-Dashboard für den Anfrage-Lifecycle.
Das Ergebnis blieb trotzdem schlank: 6 Wochen, 96 Lighthouse Performance, unter 1,2s Ladezeit und eine Zertifikatserstellung in unter 24 Stunden. Der Zeitplan ging über 5 Wochen hinaus, weil der Workflow echte Finanzdaten und eine echte operative Übergabe hatte, nicht weil das Team dekorative Features ergänzte.
Mini-Story: Vibe-coded MVPs sparen Tage und verlieren dann Wochen
Am 2026-05-18 schrieben wir über Lovable, Bolt und v0 MVPs. Diese Tools sind für Prototypen nützlich, weil sie die Idee eines Gründers in Stunden sichtbar machen. Das Problem beginnt, wenn ein Prototyp als Produktfundament behandelt wird.
Das Muster ist konstant genug, dass wir eine Regel aufgeschrieben haben: Wenn eine vibe-coded App echte Nutzer hat, bauen wir sie neu, statt sie zu flicken. Ein sauberer Build auf unserem Stack dauert meist 3 bis 6 Wochen. Rettungsarbeit kann 8 bis 12 Wochen dauern, weil jede Reparatur eine Schema-, Routen- und Live-Datenstruktur respektieren muss, die niemand entworfen hat.
Das ist die weniger laute Antwort, aber sie ist fairer zum Budget. Nutzen Sie AI App Builder, um zu lernen, was das Produkt tun soll. Nutzen Sie einen MVP-Build, wenn Sie als Nächstes zuverlässige Daten von echten Nutzern brauchen.
Der 30-Minuten-Zeitplantest
Bevor Sie eine Agentur nach einem Zeitplan fragen, schicken Sie den Scope durch diesen Test. Wenn Sie ihn nicht in 30 Minuten beantworten können, ist das Projekt noch nicht bereit für einen festen Kalender.
Ein Satz: Welche riskante Annahme muss Version eins beweisen?
Ein Nutzer: Wer nutzt den ersten Release vor allen anderen?
Ein Workflow: Welche Schritte bringen diesen Nutzer vom Einstieg zum Wert?
Eine Kennzahl: Welche Zahl sagt Ihnen innerhalb von 30 Tagen, ob Sie weitermachen?
Ein Owner: Wer kann Scope innerhalb von 24 Stunden kürzen oder akzeptieren?
Bekannte Accounts: Welche Auth-, Payment-, E-Mail-, Analytics-, Hosting- und Datenbank-Accounts sind bereit?
Harte Kürzungen: Was wird vor Launch nicht ausgeliefert, selbst wenn jemand danach fragt?
Wenn die Antworten auf eine Seite passen, kann ein MVP in 3 bis 5 Wochen realistisch sein. Wenn die Antworten einen Workshop brauchen, beginnen Sie mit dem Brief. Die Kostenversion derselben Entscheidung steht in unserem Guide zu MVP-Entwicklungskosten.
Wann ein längeres MVP die ehrliche Antwort ist
Manche ersten Releases sollten nicht in 5 Wochen gepresst werden. Regulierte Daten, medizinische Aussagen, Finanzentscheidungen, Marketplaces, mobile App Stores und komplexe Partner-APIs können einen längeren Build rechtfertigen.
Der Test ist einfach: Schützt die zusätzliche Zeit einen echten Nutzer, eine echte Transaktion oder eine echte Rechtspflicht? Wenn ja, behalten Sie sie. Wenn die zusätzliche Zeit das Produkt nur vollständiger wirken lässt, kürzen Sie sie.
webvise hilft Gründern, diese Entscheidung zu treffen, bevor Code entsteht. Wenn Ihr MVP eng genug für 3 bis 5 Wochen sein sollte, ist unser MVP Development Service die richtige Lane. Wenn es bereits eine Produktionsplattform ist, sagen wir das und scopen anders.
Ein guter MVP-Zeitplan ist kein Flex. Er ist die Folge von klarem Scope, schnellen Entscheidungen und einer ersten Version, die eine Geschäftsfrage beantworten soll. Wenn Sie möchten, dass webvise Ihren Brief vor dem Build prüft, schicken Sie ihn uns.