MVP-Timeline-Benchmark 2026: Wie lange 30 echte Software-Builds dauerten

Die brauchbare Antwort auf "Wie lange dauert es, ein MVP zu bauen?" ist nicht "drei Monate". In unserem 2026er-Benchmark aus 30 anonymisierten Software-MVP-Builds lag die Median-Zeit vom unterschriebenen Kickoff bis zum ersten Live-Release bei 12 Kalenderwochen. Der schnellste Build ging nach 5 Wochen in einen kontrollierten Production Pilot. Der langsamste brauchte 26 Wochen. Der Unterschied lag selten am Framework. Er lag am Scope: Integrationen, Mobile-Release, unklare Entscheidungen, Datenzugang, Compliance-Fragen und QA-Tiefe.

Dieser Artikel gehört den beobachteten Zeitdaten. Wenn du einen Build-Partner suchst, starte bei unserer MVP-Entwicklung. Wenn du den kompletten Ablauf verstehen willst, nutze den Software-Development-Guide. Wenn du Belege sehen willst, lies die Cases hinter dem Muster: PromptID, Twinsoft AI, Scramble Pay und Offlinery.

Die Benchmark-Antwort

Ein produktionsfähiges Software-MVP dauerte typischerweise 10 bis 14 Wochen. Kleine interne Tools lagen bei 5 bis 12 Wochen. B2B-SaaS-MVPs lagen bei 8 bis 18 Wochen. Mobile oder Web-plus-Mobile-Builds lagen bei 12 bis 26 Wochen. KI-MVPs lagen bei 9 bis 21 Wochen, weil schnelle Prototypen durch Daten-, Eval- und Safety-Arbeit wieder gebremst wurden.

Sample-Definition und Ausschlüsse

Das Sample umfasst 30 individuelle Software-Builds, abgeschlossen zwischen Januar 2024 und Juni 2026. Jeder Build hatte einen echten Release für Nutzer oder Operators, Live-Daten oder realistische Pilotdaten, Authentifizierung wo nötig, Deployment, QA, Handover und eine Launch-Entscheidung. Wir zählen Kalenderwochen, nicht Personentage, weil Founder und Käufer Time-to-Market kaufen, nicht Jira-Stunden.

Enthalten sind B2B-SaaS-Produkte, interne Workflow-Tools, Portale, Marketplaces, Mobile Apps und KI-Produkte. Ausgeschlossen sind No-Code-Demos, reine Design-Prototypen, Strategie-Discovery ohne Build, reine QA-Rescues, Smart-Contract-Audits, Hardware-Piloten mit dominanter Firmware oder Beschaffung, und Enterprise-Programme, deren erster Release in einer mehrjährigen Roadmap verschwindet.

Median und Range nach Produkttyp

Integrationen sind der sichtbare Timeline-Treiber

Wir zählen ein System als Integration, wenn es eigene Credentials, Sandbox, Schema-Mapping, Webhook, Rate-Limit-Verhalten, Freigabe oder Produktionsabhängigkeit braucht. Ein Stripe Checkout, Google Sign-in, HubSpot Sync, SAP Export, LLM Provider, Vector Database und App-Store-Release sind separate Risiken.

Jede produktive Integration hat zwei Timelines: die Engineering-Zeit, sie zu bauen, und die Organisationszeit, um Zugang, Testdaten, Vendor-Antworten, Compliance-Freigabe und fachlichen Sign-off zu bekommen. Die zweite hat häufiger verzögert.

Mobile versus Web

Mobile dauert nicht länger, weil React Native, Flutter, Swift oder Kotlin langsam wären. Es dauert länger, weil die Release-Fläche größer ist: Location, Kamera, Background-Verhalten, Push, Deep Links, Account Deletion, Privacy Labels, Screenshots und Store Copy. Google Play weist darauf hin, dass Reviews bei bestimmten Accounts bis zu sieben Tage oder in Ausnahmefällen länger dauern können. Apple App Review bleibt ebenfalls ein echtes Release-Gate.

KI versus konventionelles SaaS

DORAs 2024er-Report ist hier eine gute Warnung: KI kann individuelle Produktivität und Flow verbessern und trotzdem Delivery-Stabilität und Throughput verschlechtern, wenn das Delivery-System schwach ist. Studien sind gemischt: Ein Google-RCT mit 96 Engineers fand rund 21% weniger Task-Zeit, ein Open-Source-RCT von 2025 fand bei erfahrenen Entwicklern in reifen Repos 19% Verlangsamung. Unsere Beobachtung ist enger: KI ließ Prototypen schneller aussehen, entfernte aber Discovery, QA, Daten-Governance und Launch-Arbeit nicht.

Discovery, Build, QA und Launch getrennt

Die Phasen-Mediane addieren sich nicht perfekt zum Gesamt-Median, weil Phasen überlappen. Genau deshalb ist die Aufteilung nützlich: Wenn ein 10-Wochen-Estimate Discovery, QA und Launch nicht sichtbar zeigt, sind sie meist in "Development" versteckt.

Verzögerungen: Client, Engineering, Plattform

Nach Delay-Tagen entfielen grob 58% auf Client-seitige Themen, 29% auf Engineering und 13% auf Third Parties oder Plattformen. Die teuerste Client-Verzögerung war fast nie "Feedback kam zwei Tage später". Es war Entscheidungsunklarheit: Ein Feature war gebaut und wurde danach von einem Stakeholder anders interpretiert, der nicht in Discovery war.

So nutzt du den Benchmark

1. Starte mit der Plattform. Web-only kann oft 8 bis 12 Wochen anpeilen. Mobile oder Web-plus-Mobile eher 12 bis 20 Wochen, wenn der Scope nicht winzig ist.
2. Zähle Integrationen vor Screens. Sieben Screens und sechs Integrationen sind riskanter als zwanzig Screens und eine Datenbank.
3. Discovery muss Ausschlüsse produzieren. Wenn v1 nicht sagt, was nicht drin ist, ist die Timeline Fiktion.
4. Budgetiere QA als Phase. Ein MVP darf klein sein. Es darf nicht dort ungetestet sein, wo Vertrauen, Geld, Daten oder Safety betroffen sind.
5. Benenn Decision Owner. Jede Integration, Rechtsfrage, Copy-Fläche, Workflow-Ausnahme und jedes Launch Asset braucht vor Build-Start einen Owner.
6. Behandle KI als Validierungsarbeit. Addiere Evals, Fallback, Logging und menschliche Review, wenn Modellfehler echten Geschäftsschaden haben.

Quellen und Benchmark-Caveat

Dieser Benchmark basiert auf anonymisierten Wavect-Delivery-Daten und Retrospektiven. Er ist richtungsweisend, keine repräsentative Branchenstudie. Die externe Forschung stützt die Vorsicht bei Estimation: Eine systematische Mapping-Studie zu MVP-Praktiken fand wenig Forschung zu technischer Machbarkeit und Aufwandsschätzung bei MVPs. DORA warnt zudem davor, sehr unterschiedliche Anwendungen ohne Kontext zu vergleichen. Für Mobile-Launches prüfe Apple App Review und Google Play Publishing. Für KI-Kontext siehe DORA 2024, DORA Metrics, die MVP-Mapping-Studie, den Google-AI-Produktivitäts-RCT und den Open-Source-AI-Produktivitäts-RCT 2025.