Zeitplan auf einen Blick
Bevor wir ins Detail gehen, hier die realistischen Wochenbereiche für die wichtigsten Produkttypen mit einem erfahrenen Nearshore-EU-Team. Jede Angabe setzt ein ordentlich ausgearbeitetes Brief beim Kickoff voraus — Teams, die mit einem groben Konzept beginnen, müssen 3–5 Wochen Discovery hinzurechnen, bevor der folgende Zeitplan startet.
| Produkttyp | MVP / erster Launch | Produktionsreife v1 | Enterprise / skaliert |
|---|---|---|---|
| SaaS-Plattform | 10–16 Wochen | 20–28 Wochen | 36–52 Wochen |
| B2B-Portal / kundenorientierte Plattform | 12–18 Wochen | 22–32 Wochen | 40–56 Wochen |
| Zweiseitiger Marktplatz | 18–26 Wochen | 32–48 Wochen | 52–80 Wochen |
| Enterprise-Webplattform | 24–36 Wochen | 40–60 Wochen | 60–100 Wochen |
Diese Bereiche setzen eine aggressive Parallelisierung voraus (Design läuft parallel zum Backend-Scaffolding, QA ist ab Sprint 1 eingebettet) und ein Team mit direkter Erfahrung im jeweiligen Produkttyp. Sequenzielle Wasserfall-Ansätze für denselben Umfang verlängern den Kalenderzeit um 40–60 %. Wenn Sie auch das Budget bewerten, lesen Sie unseren Begleitartikel über die Entwicklungskosten für Web-Apps im Jahr 2026 — Zeitplan und Budget sind immer voneinander abhängig.
Die fünf Phasen eines Web-App-Projekts
Jedes Webanwendungsprojekt, unabhängig von seiner Größe, durchläuft fünf erkennbare Phasen. Das kalendarische Gewicht jeder Phase variiert je nach Produkttyp und Team-Reife, aber keine Phase kann übersprungen werden, ohne dass es später zu Problemen kommt.
Phase 1 — Discovery (Wochen 1–3)
Die Discovery-Phase wandelt ein Geschäftsproblem in eine umsetzbare Spezifikation um. Ergebnis: User Stories, Wireframe-Skizzen, Architecture Decision Records (ADRs), ein Risikoregister und ein aktualisierter Projektplan. Teams, die die Discovery überspringen — oder sie auf ein einziges Kickoff-Gespräch reduzieren — stellen in der Regel fest, dass ihre ursprüngliche Schätzung in der Build-Phase um 40–80 % abweicht.
Die Discovery-Dauer wird hauptsächlich durch die Anzahl der Integrationen und Benutzerrollen bestimmt. Ein schlankes Zwei-Rollen-SaaS (Endbenutzer + Admin) mit einer Zahlungsintegration kann die Discovery in 2 Wochen abschließen. Ein Marktplatz mit Käufer-, Verkäufer-, Ops- und Admin-Rollen sowie Stripe, Salesforce und einem Legacy-ERP kann allein 4–6 Wochen Discovery benötigen.
Phase 2 — Design (Wochen 2–7)
Das Design überschneidet sich erheblich mit der zweiten Hälfte der Discovery und der ersten Hälfte der Build-Phase. Ein typisches Design-Engagement umfasst: Informationsarchitektur, Low-Fidelity-Wireframes, High-Fidelity-UI-Designs, eine Komponentenbibliothek (Design-Tokens, Typografie, Farbsystem, Abstandsskala) und Developer-Handoff in Figma. Für einen MVP mit 20 Screens sind 3–5 Wochen zu veranschlagen. Für eine Produktionsplattform mit 60 Screens 6–10 Wochen. Die Verwendung eines etablierten Design-Systems wie Material Design oder Radix Themes als Ausgangspunkt komprimiert die Komponentenbibliotheks-Arbeit um 30–50 %.
Phase 3 — Build (Wochen 4–16+)
In der Build-Phase laufen Backend- und Frontend-Tracks parallel. Backend-Teams richten Infrastruktur ein (Cloud-Bereitstellung, CI/CD, Umgebungen), implementieren das Datenmodell und die API-Schicht, fügen dann Geschäftslogik und Integrationen hinzu. Frontend-Teams konsumieren die API-Verträge — die vor dem Aufbau von Screens als Spec vereinbart werden sollten — und implementieren die Benutzeroberfläche gemäß den finalisierten Designs.
Phase 4 — QA (Wochen 10–17)
QA beginnt in Sprint 1, nicht am Ende der Build-Phase. Eingebettete QA-Engineers schreiben Testfälle gegen User Stories, sobald Features auf Staging landen, anstatt am Ende einen Berg ungetesteten Codes zu erben. End-to-End-Tests (Playwright, Cypress), Load-Tests (k6, Locust) und ein Sicherheitsscan (OWASP ZAP, Burp Suite Basic) sollten vor dem Launch abgeschlossen sein.
Phase 5 — Launch (Wochen 15–18+)
Der Launch ist kein einzelnes Ereignis. Es ist ein 2–3-wöchiger Zeitraum, der einen Soft Launch für eine begrenzte Benutzergruppe, die Einrichtung von Monitoring und Incident-Response, die Erfassung einer Performance-Baseline, finales Produktions-Hardening und dann den vollständigen öffentlichen Rollout umfasst.
MVP vs. vollständiger Build: Wie sich Zeitpläne unterscheiden
Der Begriff "MVP" wird so ungenau verwendet, dass es sinnvoll ist, ihn zu präzisieren. Im Kontext eines Web-App-Projekts ist ein MVP das Kleinste, was Sie liefern können, das echten Benutzern ermöglicht, den wertvollsten Job des Produkts zu erledigen, Signal darüber generiert, ob Sie einen Problem-Solution-Fit haben, und Ihre Marke gegenüber potenziellen Enterprise-Käufern nicht in Verlegenheit bringt.
Ein MVP ist kein Prototyp oder Proof of Concept. Es ist Produktionscode auf Produktionsinfrastruktur mit echter Authentifizierung, echter Datenpersistierung und einem echten Zahlungsablauf, wenn Ihr Produkt etwas in Rechnung stellt. Der Unterschied zu einer produktionsreifen v1 liegt im Umfang, nicht in der Qualität.
| Dimension | MVP | Produktionsreife v1 |
|---|---|---|
| Abgedeckte User Flows | 1 primärer, 1–2 sekundäre | Alle geplanten Flows + Edge Cases |
| Design-System | Angepasste Komponentenbibliothek | Vollständiges individuelles Design-System |
| Integrationen | 1–2 kritische (z. B. Zahlungen, Auth) | Vollständige Integrations-Suite |
| Rollenbasierte Zugriffskontrolle | 2 Rollen (Benutzer + Admin) | Vollständiges RBAC mit Berechtigungsmatrix |
| Reporting / Analysen | Einfaches Admin-Dashboard | Vollständige Reporting-Suite + Exporte |
| Compliance-Tools | Grundlegender DSGVO-Consent + Cookie-Banner | Vollständige DSR-Flows, Audit-Logs, DPAs |
| Typischer Zeitplan | 10–16 Wochen | 20–32 Wochen |
Der Sprung vom MVP zur v1 ist selten eine 20–30 %-ige Scopeerhöhung. In den meisten von uns gelieferten Projekten stellt der zusätzliche Umfang für v1 das 2–3-fache des MVP-Umfangs dar. Budget- und Zeitplanung sollten dies widerspiegeln. Eine vollständige Aufschlüsselung dessen, was den Projektumfang und die Kosten neben dem Zeitplan treibt, finden Sie in unserem Leitfaden zu den Entwicklungskosten für Web-Apps.
Worked Example: 16-wöchiger SaaS-MVP
Die folgende Tabelle zeigt den phasenweisen Zeitplan für einen realen SaaS-MVP, den wir geliefert haben: eine B2B-Analyseplattform mit zwei Benutzerrollen (Analyst und Admin), Stripe-Abonnementabrechnung, einer Datenerfassungs-API und einem React-basierten Dashboard. Team: 1 PM, 1 Produktdesigner, 2 Backend-Engineers, 2 Frontend-Engineers, 1 QA-Engineer.
| Phase / Track | Wochen | Wichtige Deliverables | Wer |
|---|---|---|---|
| Discovery | 1–3 | User Stories, Datenmodell, ADRs, Risikoregister | PM + Backend Lead |
| UX / UI Design | 2–7 | Wireframes, Figma-Designs (22 Screens), Design-Tokens | Designer |
| Backend: Infra + Auth | 1–4 | AWS-Setup, CI/CD, Auth-Service, DB-Schema | Backend #1 + #2 |
| Backend: API + Integrationen | 4–11 | REST-API, Stripe-Billing, Ingestion-Endpoint, Admin-APIs | Backend #1 + #2 |
| Frontend: Komponentenbibliothek | 5–8 | Design-System in React (MUI-Basis), Core-Layout-Komponenten | Frontend #1 |
| Frontend: Features | 7–13 | Dashboard, Analyseansichten, Admin-Panel, Billing-UI | Frontend #1 + #2 |
| QA (kontinuierlich) | 4–15 | Testfälle, Regression, E2E-Suite (Playwright), Load-Test | QA-Engineer |
| Soft Launch + Hardening | 14–16 | Beta-Benutzergruppe, Monitoring (Datadog), Bug-Fix-Sprint, Go-Live | Gesamtes Team |
Gesamte Kalenderzeit: 16 Wochen. Gesamte Personenwochen: ca. 98 (7 Personen × 14 aktive Wochen im Durchschnitt). Der Schlüssel zum Erreichen der 16-Wochen-Marke war der Start der Backend-Infrastruktur in Woche 1 — noch bevor UI-Designs existierten — und die Vereinbarung von API-Verträgen (OpenAPI-Spec) als gemeinsames Artefakt, gegen das beide Teams ab Woche 5 arbeiteten.
Was den Zeitplan komprimiert
Es gibt fünf Hebel, die einen Web-App-Entwicklungszeitplan zuverlässig komprimieren, ohne die Qualität zu beeinträchtigen. Jeder ist eine Prozess- oder Architekturentscheidung, keine "Arbeitet härter"-Anweisung.
1. Discovery, Design und Backend-Scaffolding parallelisieren
Der wirkungsvollste Zeitplan-Kompressor ist der Start von Backend-Infrastruktur und Scaffolding in Woche 1, gleichzeitig mit Discovery und Design, anstatt auf den Abschluss des Designs zu warten, bevor Code geschrieben wird. Cloud-Bereitstellung, CI/CD-Pipeline-Setup, Authentifizierungsservice, Datenbankschema und API-Struktur können alle aufgebaut werden, bevor ein einzelner UI-Screen designt ist. Bei einem 16-wöchigen Projekt spart dieser parallele Start 3–5 Wochen Kalenderzeit.
2. Eine etablierte Komponentenbibliothek verwenden
Ein Design-System von Grund auf neu aufzubauen — individuelle Farbtokens, ein vollständiger Icon-Satz, individuelle Animationsbibliothek, barrierefreiheitsorientierte Komponentenvarianten — dauert 4–8 Wochen. Die Anpassung einer etablierten Bibliothek wie MUI, Radix Themes oder Shadcn/UI dauert 1–2 Wochen. Das visuelle Ergebnis ist für Benutzer nicht zu unterscheiden. Für einen MVP, bei dem der schnelle Markteintritt das primäre Ziel ist, sind individuelle Design-Systeme ein Luxus, der auf v2 warten kann.
3. QA ab Sprint 1 einbetten
Teams, die QA-Engineers nur am Ende der Build-Phase hinzufügen, stehen regelmäßig vor einem 3–5-wöchigen Bug-Fix-Crunch vor dem Launch. Die Einbettung eines QA-Engineers ab dem ersten Sprint bedeutet, dass Bugs innerhalb des Sprints gefunden und behoben werden, in dem sie eingeführt werden, anstatt über 12 Wochen angesammelt und am Ende als Fehlerberre zurückgegeben zu werden. Für weitere Informationen darüber, wie Architekturentscheidungen die langfristige Zeitplangesundheit beeinflussen, lesen Sie unseren Leitfaden zu Monolith vs. Microservices.
4. API-Verträge vor dem Build vereinbaren
Frontend- und Backend-Teams, die parallel arbeiten, benötigen einen gemeinsamen Vertrag — ein OpenAPI- oder GraphQL-Schema — den beide Seiten als Quelle der Wahrheit behandeln. Ohne diesen müssen Frontend-Teams entweder auf Backend-APIs warten, bevor sie Screens bauen, oder gegen Annahmen bauen, die sich als falsch herausstellen. API-First-Design, bei dem Schema-Dateien in Woche 2 oder 3 committet werden, bevor eine Implementierung existiert, ermöglicht echte Frontend-Backend-Parallelisierung.
5. Integrationen auf das beschränken, was der MVP wirklich braucht
Jede Drittanbieterintegration ist ein Mini-Projekt mit eigenen undokumentierten Edge Cases, Sandbox-zu-Produktions-Unterschieden und Rate-Limits. Eine typische Integration dauert 1–3 Wochen. Eine Integration mit einem komplexen Legacy-System (ERP, CRM mit individuellem Datenmodell, Finanzdatenanbieter) kann 4–8 Wochen dauern. Das Verschieben nicht-kritischer Integrationen vom MVP auf v1 ist eine der einfachsten und wirkungsvollsten Scope-Entscheidungen.
Häufige Verzögerungsursachen und wie man sie vermeidet
In unseren Lieferdaten aus 40+ Webplattform-Projekten sind die häufigsten Ursachen für Terminüberschreitungen konsistent und weitgehend vermeidbar. Beachten Sie, dass keine davon grundlegend technischer Natur ist — es handelt sich um Prozess- und Kommunikationsfehler.
| Verzögerungsursache | Typische Auswirkung | Vermeidungstaktik |
|---|---|---|
| Scope-Creep (neue Anforderungen mitten im Sprint) | +3–8 Wochen | Change-Control-Prozess: neue Anforderung = etwas Gleichwertiges entfernen oder für v1-Backlog zurückstellen |
| Engpass bei Stakeholder-Reviews | +2–4 Wochen | Dedizierte Review-Zeit in Stakeholder-Kalendern reservieren; 48-Stunden-Feedback-SLA definieren |
| Unerwartete Probleme bei Drittanbieter-APIs | +1–4 Wochen pro Integration | Jede Integration in Woche 1–2 der Discovery spiken; nie annehmen, dass Sandbox = Produktionsverhalten |
| Nacharbeiten beim Design-Handoff | +1–3 Wochen | Engineers prüfen Figma-Designs vor Entwicklungsbeginn; mehrdeutige States, leere States, Fehlerstates frühzeitig kennzeichnen |
| Spätes QA-Gate | +3–6 Wochen | QA ab Sprint 1 einbetten; Regression bei jedem Sprint ausführen, nicht nur beim letzten Sprint |
| Verzögerungen bei der Infrastrukturbereitstellung | +1–2 Wochen | Cloud-Umgebungen in Woche 1 mit Infrastructure as Code bereitstellen (Terraform, Pulumi) |
Parallelisierung: Der größte Zeitplan-Hebel
Das einzelne wirkungsvollste Konzept im Web-App-Zeitplanmanagement ist die Parallelisierung — das gleichzeitige Ausführen von Discovery, Design, Backend und QA als simultane Tracks statt als sequenzielle Phasen. Der Unterschied im Kalenderergebnis ist dramatisch.
Betrachten Sie ein produktionsreifes B2B-Portal mit 40 Screens, 3 Benutzerrollen und 4 Integrationen. Sequenzielle Wasserfall-Lieferung:
- Discovery: 4 Wochen
- Design: 8 Wochen (beginnt nach Discovery)
- Build: 16 Wochen (beginnt nach Design)
- QA: 6 Wochen (beginnt nach Build)
- Launch: 2 Wochen
- Gesamt: 36 Wochen
Dasselbe Projekt mit aggressiver Parallelisierung:
- Discovery + Design-Überschneidung: Wochen 1–6 (gleichzeitig laufend)
- Backend-Scaffolding: beginnt Woche 1 (läuft parallel zur Discovery)
- Frontend: beginnt Woche 5 (gegen vereinbarte API-Verträge)
- QA: beginnt Woche 4 (in Build-Sprints eingebettet)
- Integrations-Sprint: Wochen 14–18 (dediziertes Integrations-Hardening)
- Launch: Wochen 20–22
- Gesamt: 22 Wochen
Gleicher Umfang. Gleiche Teamgröße. 14 Wochen gespart — eine 39 %-ige Kalenderreduzierung — rein durch Parallelisierung. Deshalb kann die Frage "wie lange" nicht beantwortet werden, ohne auch zu fragen "wie führen Sie das Projekt durch?"
Für technische Teams, die Architekturentscheidungen evaluieren, die auch die langfristige Wartbarkeit beeinflussen, behandelt unser Artikel über Next.js vs. React für B2B-Web-Apps Framework-Entscheidungen, die bedeutende Zeitplanauswirkungen haben. Und für Produkt-Architekturentscheidungen, die den langfristigen Zeitplan beeinflussen, lesen Sie unseren Leitfaden zu Monolith vs. Microservices.
Wie Teamgröße und Seniorität den Zeitplan beeinflussen
Brooks' Gesetz — "das Hinzufügen von Arbeitskraft zu einem späten Softwareprojekt macht es später" — ist im Jahr 2026 genauso gültig wie 1975. Aber Teamzusammensetzungsentscheidungen, die zu Beginn eines Projekts getroffen werden, haben eine signifikante und vorhersagbare Auswirkung auf den Zeitplan.
| Teamzusammensetzung | Geschätzter Zeitplan | Wichtigstes Risiko |
|---|---|---|
| 4 Seniors (2 BE + 2 FE) + 1 Senior QA + 1 PM | 14–16 Wochen | Geringes Risiko — Seniors treffen Architekturentscheidungen eigenständig |
| 6 Mids (3 BE + 3 FE) + 1 QA + 1 PM | 18–22 Wochen | Mehr Code-Reviews, mehr Architektur-Beratung erforderlich; langsamere Entscheidungsschleifen |
| 2 Seniors + 6 Juniors + 1 QA + 1 PM | 24–32 Wochen | Hoher Betreuungsaufwand; Juniors blockieren bei Entscheidungen; erhebliches Nacharbeitsrisiko |
| Gründer solo + Freelancer (kein PM) | 30–52 Wochen | Koordinierungs- und Kontextwechsel-Overhead; niemand besitzt den kritischen Pfad |
Das Senior-geführte Team ist nicht nur schneller — es ist vorhersagbarer. Senior-Engineers treffen Architekturentscheidungen autonom, schreiben Code, der nicht in Woche 10 neu geschrieben werden muss, und identifizieren Integrationsprobleme während der Sprint-Planung. Um unseren Webanwendungsentwicklungsservice zu erkunden und wie wir Engagements besetzen, besuchen Sie unsere Serviceseite.
FAQ
Wie lange dauert die Entwicklung einer Web-App im Jahr 2026?
Ein Web-App-MVP dauert mit einem erfahrenen Nearshore-Team typischerweise 10–16 Wochen vom Kickoff bis zum Launch. Eine produktionsreife v1 mit vollständigem Design-System, Integrationen und Compliance-Anforderungen dauert 20–32 Wochen. Komplexe Unternehmensplattformen mit mehreren Benutzerrollen, Echtzeit-Funktionen und regulatorischen Anforderungen können 40–60 Wochen in Anspruch nehmen. Die größte Variable ist die Klarheit des Umfangs beim Kickoff.
Was ist der schnellste Weg, einen Web-App-MVP zu liefern?
Die Parallelisierung von Discovery und Design mit dem Backend-Scaffolding ist der wirkungsvollste Zeitplan-Kompressor. Der Start von Backend-Infrastruktur, CI/CD und Authentifizierung in Woche 1 — während UI-Designs noch parallel fertiggestellt werden — spart 3–5 Wochen bei einem 14-wöchigen Projekt. Der Einsatz einer etablierten Komponentenbibliothek (MUI, Radix, Shadcn) statt eines individuellen Design-Systems spart weitere 2–4 Wochen. Ein dedizierter QA-Engineer, der ab Sprint 1 eingebettet ist, vermeidet einen 2–3-wöchigen abschließenden Bug-Fix-Crunch.
Was verursacht die meisten Verzögerungen bei Web-App-Projekten?
Laut unseren Lieferdaten sind die drei häufigsten Ursachen für Terminüberschreitungen: (1) Scope-Creep — neue Anforderungen werden mitten im Sprint hinzugefügt, ohne dass etwas entfernt wird, was für 40–50 % der Überläufe verantwortlich ist; (2) unerwartete Probleme bei der Integration von Drittanbieter-APIs; und (3) Engpässe bei der Überprüfung durch Stakeholder. Alle drei sind Prozessprobleme, keine technischen Probleme.
Wie unterscheidet sich der MVP-Zeitplan von einem vollständigen Build?
Ein MVP reduziert das Produkt auf die wichtigste Benutzerreise und liefert es mit minimaler Infrastruktur. Ein typischer MVP dauert 10–16 Wochen. Eine produktionsreife v1 fügt ein vollständiges Design-System, rollenbasierte Zugriffssteuerung, Reporting, Integrationen und Compliance-Tools hinzu — typischerweise 20–32 Wochen. Der Sprung vom MVP zur v1 ist selten linear: der zusätzliche Umfang beträgt häufig das 2–3-fache des MVP-Umfangs.
Beeinflusst die Wahl des Tech-Stacks den Entwicklungszeitraum?
Ja, aber weniger als die meisten Gründer erwarten. Die Wahl von Next.js statt eines individuellen React-Setups spart 1–2 Wochen bei Routing und SSR-Konfiguration. Das größere Stack-bedingte Zeitplanrisiko ist die Wahl einer unbekannten Technologie: Ein Team, das zum ersten Mal von Node.js zu Go wechselt, verliert 4–6 Wochen für die Einarbeitung bei einem 16-wöchigen Projekt. Setzen Sie auf den Stack, mit dem Ihr Team täglich liefert.
Wie soll ich die Projektzeitplan-Tabelle lesen?
Das Worked Example zeigt einen 16-wöchigen SaaS-MVP, bei dem Discovery, Design und Backend-Scaffolding parallel in den Wochen 1–4 laufen, die Frontend-Implementierung in den Wochen 5–12 parallel zur Backend-Entwicklung läuft, die QA-Härtung in den Wochen 11–14 stattfindet und ein Soft-Launch-Puffer in den Wochen 15–16 vorgesehen ist. Parallelisierung macht 16 Wochen erst möglich — ein sequenzielles Wasserfallmodell für denselben Umfang würde 28–32 Wochen dauern.
Veröffentlicht am 9. Juni 2026. Zeitplanbereiche basieren auf YuSMP Group Lieferdaten 2023–2026. Alle Angaben setzen ein Senior Nearshore EU Team voraus. Methodologie auf Anfrage erhältlich.
