Warum 90 Tage realistisch sind – und was sie verhindern
Die meisten B2B-Website-Projekte, die wir aus zweiter Hand kennen, dauern neun bis achtzehn Monate. Sie beginnen mit einem Kickoff voller Energie, verlieren nach drei Monaten an Schwung, kommen nach sechs Monaten in eine Schleife aus Stakeholder-Reviews, und gehen am Ende mit halber Kraft live – oft mit dem Gefühl, dass das Ergebnis längst nicht das ist, was am Anfang besprochen wurde. Diese Projektart ist nicht zwangsläufig falsch, aber sie ist meistens unnötig. Für eine professionelle B2B-Marketing-Site reichen 90 Tage vom Pitch zum Go-Live, wenn man bestimmte Dinge anders macht.
Wir nennen das hier nicht „unser Framework“, weil es klingt wie eine Methode mit Logo. Es ist eher eine Sammlung von Entscheidungen, die wir in den letzten Jahren in mehreren Projekten getroffen haben – jede einzelne aus dem Schmerz heraus, dass die Alternative länger gedauert hätte. Dieser Artikel beschreibt die wichtigsten davon. Ziel: dass du beim nächsten Website-Projekt ein realistisches Bild davon hast, wie schnell es gehen kann – und woran es liegt, wenn es nicht so schnell geht.
Tag 0–10: Discovery in einer Woche statt in einem Monat
Klassische Discovery-Phasen dauern vier bis sechs Wochen. Sie produzieren Personas, Customer Journeys, Sitemaps, Workshops mit allen Beteiligten, lange Dokumente, die niemand mehr liest. Wir machen das in einer Woche. Tag eins: Halbtags-Workshop mit drei bis fünf Schlüsselpersonen – nicht mit allen, die involviert sein wollen, sondern mit denen, die entscheiden dürfen. Tag zwei und drei: Konsolidierung der Inhalte, Entwurf einer Sitemap, Entwurf der wichtigsten zwei oder drei Sektionsmuster. Tag vier: Review mit den Schlüsselpersonen, mit Entscheidungen am Tisch – nicht per E-Mail.
Was wir bewusst weglassen: ausführliche Persona-Dokumente, ausführliche Customer-Journey-Maps, langwierige Wettbewerbsanalysen. Die meisten dieser Artefakte haben in der Praxis keinen Effekt auf die finale Site – sie sind Beruhigungsmittel für Auftraggeber, nicht Werkzeuge für Designer. Wenn der Kunde sie wirklich braucht, machen wir sie später parallel zur Entwicklung. Wenn er sie nicht wirklich braucht, sparen wir vier Wochen.
Tag 11–30: Design und Entwicklung parallel, nicht sequenziell
Der größte Zeitfresser klassischer Web-Projekte ist die strikte Trennung von Design und Entwicklung. Erst werden alle Screens designt und freigegeben, dann beginnt die Entwicklung. Das produziert lange Wartezeiten und am Ende fast immer Diskussionen, weil das Design Dinge versprach, die in der Umsetzung nicht so gut funktionieren. Wir arbeiten ab Tag elf parallel: Design entsteht in echten React-Komponenten, nicht in Figma-Screens. Was im Frontend gebaut wird, ist sofort im Browser sichtbar, klickbar, anpassbar.
Konkret: Wir bauen ab Tag elf das Designsystem direkt in Code. Drei bis fünf zentrale Sektionsmuster (Hero, Feature-Grid, Contact-Block, Testimonials, Pricing-Tabelle), jeweils als wiederverwendbare Komponenten in Next.js, gestylt mit Tailwind. Parallel dazu wird das Sanity-Schema modelliert. Bis Tag 30 steht ein klickbares, datenangebundenes Frontend mit drei bis vier echten Beispielseiten – nicht Mockups, sondern Software. Das ist der Punkt, an dem wir beim Kunden eine erste Demo haben, die er anfassen kann.
Tag 31–60: Inhalte, nicht Schleifen
Der zweite große Zeitfresser ist die Inhalts-Lieferung. Die meisten Projekte stranden hier: Das Design ist fertig, die Technik ist fertig, aber die Texte fehlen. Wochenlang. Manchmal Monate. Wir lösen das anders: In Tag 31 bis 60 ist die Hauptaufgabe nicht mehr Entwicklung, sondern Inhaltserstellung gemeinsam mit dem Kunden. Wir setzen wir uns mit den Verantwortlichen für Marketing und Produkt zusammen – manchmal vor Ort, meistens in Workshop-Sessions über Video – und schreiben die Texte gemeinsam, direkt im Sanity-Studio.
Das hat zwei Effekte. Erstens: Inhalte entstehen schneller, weil sie nicht hin- und hergeschickt werden. Zweitens: Der Kunde lernt das CMS während des Schreibens kennen, statt es nach dem Launch in einer Schulung zu überreicht zu bekommen. Bis zum Ende dieser Phase haben wir 70 bis 80 Prozent der Hauptseiten mit echten Inhalten, nicht mit Lorem Ipsum. Parallel feinoptimieren wir das Designsystem an realen Inhalten – was fast immer zu besseren Entscheidungen führt als Design auf Platzhaltertexten.
Tag 61–80: Integration, Performance, SEO
In dieser Phase kommen die Themen, die am Ende oft kleingerechnet werden und dann Probleme machen. Anbindung an das CRM (HubSpot, Pipedrive). Anbindung an die Marketing-Automation. Cookie-Management mit Einwilligungsverwaltung. Tracking-Setup, das DSGVO-konform funktioniert. Performance-Optimierung mit Blick auf Core Web Vitals. SEO-Grundlagen wie Sitemap, strukturierte Daten, Meta-Tags pro Seite, automatische OG-Image-Generierung.
Wir machen das in dieser Phase und nicht früher, weil viele dieser Themen vom finalen Inhalt abhängen. Eine SEO-Optimierung auf Lorem-Ipsum-Texten ist sinnlos. Ein Cookie-Banner, der die echten Tracking-Tools nicht kennt, ist Theater. Wir sparen Zeit, indem wir diese Schicht erst dann legen, wenn die darunter liegende Inhaltsebene steht. Bis Tag 80 ist die Site funktional komplett – alles läuft, alles ist angebunden, alles ist gemessen. Was fehlt, ist Politur.
Tag 81–90: Politur, Test, Launch
Die letzten zehn Tage sind reserviert für Dinge, die in jedem Projekt spät auftauchen, egal wie gut man plant. Browsertests, Screen-Reader-Tests für Barrierefreiheit, kleine Anpassungen am Designsystem aus echtem Nutzungsfeedback, finale SEO-Prüfung, 301-Redirects für alle alten URLs, Monitoring-Setup für nach dem Launch. Wir machen in dieser Phase auch einen Pre-Launch-Review mit allen wichtigen Stakeholdern – nicht um Designentscheidungen erneut zu öffnen, sondern um Sicherheit zu schaffen.
Der Launch selbst ist ein Nicht-Event, wenn die Vorbereitung stimmt. Wir setzen die DNS-Änderung nach Plan, beobachten Monitoring und Performance live, halten für 24 Stunden eine erhöhte Bereitschaft. In den meisten Fällen passiert in diesen 24 Stunden gar nichts – weil die unangenehmen Überraschungen schon in den Tagen vorher abgefangen wurden.
Was 90 Tage ermöglicht – und was sie verhindert
90 Tage funktionieren nur unter drei Bedingungen. Erstens: klare Entscheider auf Kundenseite. Drei bis fünf Personen, die Entscheidungen treffen dürfen, ohne nach jeder Sitzung zurück ins Komitee zu gehen. Wer einen formalen Freigabeprozess mit zwölf Stakeholdern hat, kann 90 Tage vergessen – das ist keine technische Einschränkung, sondern eine politische. Zweitens: ein klares Scope. Wir machen eine professionelle Marketing-Site, nicht ein Kundenportal mit Login, nicht eine produktnahe Web-App, nicht eine Multi-Brand-Plattform. Wer mehr als das will, braucht andere Zeiträume.
Drittens: ein Team auf unserer Seite, das die Werkzeuge im Schlaf beherrscht. Sanity, Next.js, Tailwind, die typischen Integrationen – das alles muss fließend sitzen. Wir verlieren keine Zeit damit, neue Tools zu lernen oder Architekturen zu erfinden, weil wir sie schon kennen. Genau das ist der Grund, warum 90 Tage für uns realistisch sind und für ein generisches Agentur-Team mit anderem Tech-Stack vielleicht nicht. Geschwindigkeit kommt aus Wiederholung, nicht aus Heldentaten.
Wann 90 Tage die falsche Antwort sind
Es gibt Projekte, in denen 90 Tage nicht das richtige Ziel sind. Wenn das Markenfundament noch unklar ist und während des Projekts strategisch entwickelt werden soll, brauchst du eine Markenphase vor der Webphase. Wenn es um eine echte Plattform mit komplexen Backend-Integrationen, Login-Bereich oder regulatorischen Anforderungen geht, sind 90 Tage zu wenig für saubere Arbeit. Wenn der interne Freigabeprozess zwischen fünf Abteilungen liegt, ist die Geschwindigkeit ohnehin politisch limitiert.
In all diesen Fällen ist es ehrlicher, gleich von einem längeren Zeitraum auszugehen – vier bis sechs Monate, manchmal mehr. Das ist nicht schlimm, solange es bewusst entschieden wird, statt schleichend zu passieren. Was wir in jedem Fall vermeiden wollen, ist das Muster, in dem ein Projekt mit der Erwartung von drei Monaten startet und nach acht Monaten immer noch läuft, weil unterwegs niemand den Mut hatte, die Erwartung anzupassen.
Zusammenfassung
Eine professionelle B2B-Marketing-Site kann in 90 Tagen vom Pitch zum Go-Live gehen, wenn man die richtigen Entscheidungen trifft. Discovery in einer Woche statt einem Monat. Design und Entwicklung parallel statt sequenziell. Inhalte gemeinsam im CMS schreiben statt in Word-Dokumenten hin- und herschicken. Integrationen und SEO erst dann, wenn die Inhaltsebene steht. Politur und Launch in den letzten zehn Tagen. Das funktioniert unter drei Bedingungen: klare Entscheider auf Kundenseite, klares Scope, und ein Team, das die Werkzeuge nicht erst lernen muss.
90 Tage sind nicht der richtige Rahmen für alles. Bei unklaren Markenfundamenten, echten Plattformanforderungen oder politisch komplexen Konzernumgebungen sind längere Zeiträume ehrlich nötig. Aber für die typische professionelle B2B-Site eines mittelständischen Unternehmens ist die 9-Monate-Erwartung meistens überholt – nicht weil weniger geleistet wird, sondern weil sequenzielle Prozesse und ausufernde Discovery-Phasen ihre Berechtigung verloren haben.
