Wie lange ein Website-Projekt wirklich dauert, Woche für Woche.

„Wie lange wird das dauern?“ ist die zweite Frage, die jeder Kunde stellt, direkt nach dem Preis — und die, auf die die meisten Angebote mit einer einzigen selbstsicheren Zahl antworten, die sich als falsch herausstellt. Nicht, weil jemand lügt, sondern weil ein Website-Projekt auf zwei Uhren gleichzeitig läuft: der Produktionsuhr (Discovery, Design, Bau, QA, Launch) und der Freigabeuhr (wie schnell jemand tatsächlich prüft und absegnet, was ihm geschickt wird). Die erste ist wirklich vorhersehbar. Die zweite ist die Quelle fast jeder echten Verzögerung — und wird selten als Ursache benannt. Klick dich durch die Phasen unten, um zu sehen, was in ihr passiert, was üblicherweise verzögert, und welche Meilensteine echten Fortschritt markieren.

Vom Kickoff zum Launch, Phase für Phase

Woche 0 ist der Kickoff-Call. Wähl eine Phase, um zu sehen, was in ihr passiert, was üblicherweise verzögert, und welche Meilensteine hineinfallen.

Warum die Phasen weniger ergeben, als der Kalender zeigt

Addiere die Phasenspannen — Discovery, Design, Entwicklung, QA und Launch — und du kommst auf irgendwo zwischen sechs und vierzehn Wochen echter Arbeit für eine mehrseitige Business-Website. Diese Zahl stimmt tatsächlich, und trotzdem ist sie nicht die Zahl, mit der die meisten Projekte enden — aus einem Grund, der nichts damit zu tun hat, wie schnell irgendjemand arbeitet.

Ein Website-Projekt läuft auf zwei Uhren gleichzeitig. Die eine misst die Arbeit: eine Seite designen, ein Template bauen, ein Formular testen. Die andere misst die Lücken zwischen der Arbeit — die Tage, die ein Design in irgendjemandes Posteingang liegt, bevor es geöffnet wird, die Woche, in der eine Content-Frist still verstreicht, das „lass uns dazu nochmal zusammensetzen“, das länger dauert, terminiert zu werden, als das Treffen selbst dauert. Die erste Uhr ist die, die ein Angebot zitiert. Die zweite entscheidet tatsächlich über das Fertigstellungsdatum.

Das ist kein Problem, das nur die Webbranche betrifft. Eine Umfrage 2025 unter 500 Marketing- und Kreativfachleuten ergab, dass über 60% bis zu einem vollen Arbeitstag pro Woche allein mit dem Nachjagen von Freigaben verlieren, und 74% sagten, der Freigabeprozess koste mehr Aufwand als die geprüfte kreative Arbeit selbst. Das ist die zweite Uhr, direkt gemessen.

Wo die zwei Uhren auseinanderlaufen, Phase für Phase

Discovery ist die einzige Phase, in der die zwei Uhren größtenteils übereinstimmen — es gibt noch sehr wenig freizugeben, nur Entscheidungen, die einmal getroffen werden müssen. Genau deshalb lohnt es sich, Scope, Content-Verantwortung und Plattform-Entscheidung so ernst zu nehmen, wie dieser Leitfaden es tut: Eine Korrektur kostet hier ein Gespräch. Dieselbe Korrektur, gefunden im dritten Monat der Entwicklung, kostet einen Neubau.

Beim Design öffnet sich meist die Lücke. Veröffentlichte Schätzungen setzen die Arbeit selbst bei zwei bis sechs Wochen an — aber diese Spanne setzt voraus, dass Feedback in Tagen zurückkommt, nicht im nächsten Sprint. Eine Strategie-Session, die den Scope klärt, bevor das Design beginnt, ist eine günstige Versicherung genau gegen diese Lücke — im Vergleich dazu, direkt ins Visuelle zu springen und zu hoffen.

Bei der Entwicklung liegt die Lücke häufiger am Content als am Feedback. Ein Build kann code-fertig sein, ohne dass ein einziger Text geschrieben ist, und „code-fertig“ ist kein Meilenstein, den ein Kunde sehen kann — was bedeutet, dass es sich nicht nach Fortschritt anfühlt, selbst wenn es welcher ist. Ein Business-Website-Engagement legt die Content-Verantwortung genau deshalb schriftlich beim Kickoff fest.

Beim Launch ist die Lücke theoretisch am kürzesten und praktisch am längsten, weil eine „finale Prüfung“ gerne zu einer weiteren Design-Runde wird — genau in dem Moment, in dem alle am wenigsten darauf vorbereitet sind, eine Verzögerung zu verkraften. Diese Grenze zu schützen ist mehr wert als jede technische Aufgabe am Launch-Tag.

Was eine Timeline wirklich verkürzt, und was es nur scheint

Fester Scope und gedeckelte Überarbeitungen verkürzen Timelines. Nicht, weil sie Uneinigkeit verhindern, sondern weil sie jede Uneinigkeit an einen Moment verschieben, an dem sie günstig zu lösen ist — das Scoping-Gespräch — statt an einen Moment, an dem sie teuer ist — die vierte ungeplante Design-Runde.

Ein einziger namentlich benannter Freigeber pro Phase verkürzt Timelines zuverlässiger als alles, was mit dem Bau selbst zu tun hat. Ein Technisches Audit vor einem Redesign hat denselben Effekt auf die Entwicklungsphase: Es macht aus „wir finden die Integrationen unterwegs heraus“ eine Liste, die feststeht, bevor jemand anfängt, Stunden dafür abzurechnen, sie zu entdecken.

Was nicht hilft: mehr Leute eine Entscheidung prüfen zu lassen, „nur um sicherzugehen“. Mehr Prüfer erzeugen mehr Meinungen, nicht mehr Klarheit, und drei widersprüchliche Meinungen zusammenzuführen dauert messbar länger, als die Einschätzung einer einzigen Person zu akzeptieren.

Was ebenfalls nicht hilft: für einen schnelleren Bau zu zahlen. Die Codierzeit zu komprimieren ändert nichts an den Freigabelücken, wo die eigentliche Zeit verloren geht — derselbe Fehler wie zu erwarten, dass ein größeres Budget beschleunigt, wie schnell Google eine Seite indexiert.

Wie wir das in der Praxis umreißen

Ein Business-Website-Engagement beginnt mit dem Scoping-Gespräch, das dieser Leitfaden als Phase eins beschreibt — schriftlich, bevor die Design-Arbeit beginnt —, weil die Korrektur hier fast kostenlos ist und danach überall teuer.

Wenn der Scope die offene Frage ist, nicht das Design selbst, ist eine Strategie-Session der günstigere Weg, sie zu beantworten: ein kurzes, bezahltes Engagement, das die Sitemap, die Plattform-Entscheidung und den Content-Plan liefert, bevor überhaupt ein Design-Tool geöffnet wird.

Nach dem Launch ist das Stabilisierungsfenster der Punkt, an dem eine Website entweder in Ruhe gelassen wird, bis etwas kaputtgeht, oder einen richtigen ersten Monat Aufmerksamkeit bekommt — Content-Updates, Monitoring, die kleinen Korrekturen, die echter Traffic zutage bringt und die Staging nie gezeigt hat. Genau dafür ist eine Monatliche Wartung gedacht, statt als nachträglicher Gedanke verkauft zu werden.

Quellen

Die Phasenspannen und die Zahlen zu Freigabeverzögerungen oben stammen aus diesen, geprüft im August 2026. Die wöchentliche Struktur und die Meilensteine sind unsere eigenen, aus Kundenprojekten.

• Designveloper — Web Development Timeline: How Long Does It Take to Build a Website? ↗

  Phasenweise Schätzung: Planung 1–2 Wochen, UI/UX-Design 2–4 Wochen, Entwicklung 4–12 Wochen, Testing/QA 1–3 Wochen, Deployment 1 Woche — und identifiziert Feedback-Geschwindigkeit des Kunden als einen der größten Timeline-Treiber.

• Ramotion — Website Development Timeline: Stages, Timeline & Breakdown ↗

  Eine zweite, unabhängige Phasenaufteilung (Planung 1–2 Wochen, Design 3–6 Wochen, Bau 4–8 Wochen, Testing/Launch 2–4 Wochen) plus typische Gesamtdauer nach Projekttyp, von einer Ein-Seiten-Website (1–2 Wochen) bis zu einer individuellen Plattform (6+ Monate).

• StreamWork — 2025 Approval Research Study ↗

  Umfrage unter 500 US-amerikanischen Marketing- und Kreativfachleuten, durchgeführt von Pollfish, 7.–22. Oktober 2025: über 60% verlieren bis zu einem vollen Arbeitstag pro Woche mit dem Nachjagen von Freigaben, 74% sagen, der Freigabeprozess koste mehr Aufwand als die kreative Arbeit selbst, und über drei Viertel gaben an, Freigabeverzögerungen hätten direkt Budget verschwendet.