Website-Development-Brief: Vorlage für Founder

Ein Website-Build geht schief, wenn das Kickoff ein Loom, ein Figma-Moodboard und die Hoffnung ist, dass alle dieselbe Definition von „fertig“ teilen. Founder spüren das zuerst. Sie zahlen für eine Site, die Leads gewinnen, das Produkt erklären oder eine Funding-Runde schließen soll – und bekommen endlos Politur an den falschen Seiten.

Ein Website-Development-Brief ist das kurze Dokument, das das behebt. Es sagt, was Sie bauen, für wen, was in und außer Scope liegt, wer welche Accounts besitzt und wie Sie die Arbeit abnehmen. Dieser Leitfaden gibt Ihnen eine copy-ready Brief-Vorlage plus den Grund für jeden Block, damit Sie Freelancer, Agentur oder Inhouse-Builder briefen können, ohne dieselben Lücken mitten im Sprint neu zu entdecken.

Warum ein Brief einen vagen Kickoff-Call schlägt

Kickoff-Calls sind nützlich für Ton und Vertrauen. Als einzige Wahrheitsquelle sind sie schlecht. Leute erinnern sich an unterschiedliche Sätze. Slack-Threads begraben die eine Entscheidung, die zählte. Drei Wochen später fragt jemand, ob Blog-SEO enthalten war, und niemand kann auf eine aufgeschriebene Antwort zeigen.

Ein Brief erzwingt die harten Fragen früh, wenn Richtungswechsel billig ist. Er schützt auch den Builder. Klarer Scope ist, wie gute Freelancer ehrlich quoten und wie Sie Quotes vergleichen, ohne Äpfel-mit-Birnen-Theater.

Ein Clipboard-Brief sitzt zwischen Kickoff-Call und Build-Kalender, damit Entscheidungen schriftlich bleiben.

Zentrale Erkenntnis: Wenn eine Entscheidung nicht im Brief oder einer Amendment dazu steht, behandeln Sie sie als unentschieden. Diese eine Regel verhindert die meisten „ich dachte, wir waren einig“–Kämpfe.

Ziele und woran Sie erkennen, dass die Site funktioniert

Mit Outcomes starten, nicht mit Seitenzahl. „Wir brauchen eine Marketing-Site“ ist eine Kategorie. „Wir brauchen qualifizierte Demo-Requests von Series-A-SaaS-Käufern in US und EU“ ist ein Ziel. Maximal zwei oder drei Ziele. Mehr heißt meist, dass Sie Brand-Site, Produkt-App und Content-Engine in einen vagen Wunsch mischen.

Pro Ziel ein Success-Signal hinzufügen, das Sie in den ersten 30 bis 90 Tagen nach Launch beobachten können. Beispiele, die in einem Brief funktionieren:

• Demo-Formular-Completions pro Woche (Baseline vs. Zielspanne)
• Time-to-first-useful-page für einen neuen Besucher (Home zu Pricing oder Docs)
• Organische Impressions für ein definiertes Phrase-Cluster, sobald Search Console verbunden ist
• Support-Tickets, die aufhören, weil eine FAQ- oder Docs-Seite sie jetzt beantwortet

Setzen Sie nicht „#1 für unser Category-Keyword“ als Success-Signal, es sei denn, Sie haben schon Content- und Link-Plan. Rankings sind Outcome vieler Systeme. Ein Brief kann SEO-Erwartungen setzen (siehe später). Er sollte keine Positionen versprechen.

Ziele sitzen über Seitenlisten. Jedes Ziel hängt an einem Signal, das Sie nach Launch prüfen können.

Audience, primäre Jobs und Einwände

Die meisten Briefs überspringen Audience oder pasten eine Persona aus dem Pitch Deck. Builder brauchen Schärferes. Wer kommt an, welchen Job wollen sie erledigen, und was lässt sie gehen?

Maximal drei kurze Audience-Notizen. Für jede beantworten:

1. Wonach haben sie gerade gesucht, geklickt oder wurden sie verwiesen?
2. Welche Entscheidung versuchen sie auf diesem Besuch zu treffen?
3. Welcher Beweis würde Risiko senken (Kundenlogos, Preis-Klarheit, Security-Seite, Founder-Story)?

Wenn Sie an Käufer und User verkaufen, sagen Sie, welche Site für wen ist. Eine Founder-Produkt-Site, die Endnutzer und CFOs auf derselben Homepage convertieren will, verwässert meist beides.

Jede Audience-Notiz paart einen Job-to-be-done mit dem Beweis, der Bounce senkt.

Sitemap, Seiten und kritische Flows

Hier werden vage Projekte lieferbar. Listen Sie die Seiten, die Sie in v1 brauchen, dann die Flows, die End-to-End funktionieren müssen. Eine Seitenliste ohne Flows ist, wie Kontaktformulare kaputt ausgeliefert werden und „Demo buchen“ zu einem mailto wird, den niemand auf Mobile getestet hat.

Vorgeschlagene Form für den Brief:

• Must-ship-Seiten. Home, Produkt oder Services, Pricing (oder wie Sie verkaufen), About, Kontakt oder Demo, Legal-Seiten, die Sie wirklich brauchen.
• Should-ship, wenn Budget erlaubt. Case Studies, Blog-Index, Careers, Integrations, Status-Seite.
• Explizit später. Alles, was Sie mitten im Build erfinden wollen (Customer Portal, volle Docs-Site, Community-Forum).

Dann Flows als nummerierte Pfade listen, nicht als Features:

1. Besucher landet auf Home → Pricing → Demo-Formular → Thank-you-Seite → E-Mail-Notification an Sales.
2. Besucher landet auf einer Service-Seite → verwandte Case Study → Kontakt.
3. Returning Visitor trifft alte URL → Redirect zum neuen Pfad (Redirect-Map-Stub).

Wenn Sie schon eine Live-Site haben, aktuelle URL-Inventar anhängen und keep / merge / kill markieren. Redesigns, die die alte URL-Map ignorieren, erzeugen SEO- und Bookmark-Schaden, der wie „die neue Site hat Traffic getötet“ aussieht, obwohl der Brief nie Redirects verlangt hat.

Seitenboxen und Flow-Pfeile gehören in denselben Abschnitt, damit „fertig“ den Pfad einschließt, nicht nur das Layout.

SEO-Erwartungen, die sich lohnen aufzuschreiben

Founder sagen oft „wir brauchen SEO“ wie „wir brauchen Branding“. Builder hören entweder ein volles Content-Programm oder grundlegende technische Hygiene. Erwartung in den Brief legen, damit Quotes zur Realität passen.

Ein praktischer SEO-Block für einen Marketing-Site-Build deckt meist ab:

• Technische Baseline. HTTPS, sinnvolle URL-Struktur, XML-Sitemap, robots.txt, das Money-Pages nicht blockiert, Canonicals auf Primär-Templates, crawlbares HTML für Hauptinhalt.
• On-Page für vereinbarte Templates. Einzigartige Titles und H1s, Meta Descriptions, die Sie später editieren können, interne Links zwischen Hubs und Money-Pages.
• Analytics und Search Console. Wer Properties anlegt, wessen Google-Konto sie besitzt, und dass der Builder nur bei Bedarf Zugang bekommt.
• Content-Produktion. Sagen, ob Launch N Artikel, Migration alter Posts oder nichts einschließt. „Blog machen wir später“ ist in Ordnung, wenn es aufgeschrieben ist.
• Redirects. Erforderlich beim Ersetzen einer bestehenden Domain oder Pfadstruktur.

Was der SEO-Block nicht tun sollte: Rankings, Traffic oder eine feste Position bis Datum X garantieren. Googles eigene Leitlinien zu hilfreichem Content handeln von Nützlichkeit und Vertrauen, nicht Vendor-Versprechen. Ihr Brief kann eine crawlbar klare Site verlangen. Er kann keinen SERP-Slot kaufen.

Technische Baseline, On-Page-Templates, Search-Console-Ownership und Redirects sitzen in einem ehrlichen SEO-Abschnitt.

Häufiger Fehler: „Full SEO“ verlangen ohne Content-Budget und ohne Redirect-Map, dann das Theme beschuldigen, wenn Organic nach Redesign einbricht.

Meilensteine, Reviews und Decision Owner

Meilensteine machen aus einem Brief einen Kalender, um den Leute planen können. Wenig und konkret halten. Typische Form für eine Marketing-Site:

1. Brief locked. Sie und der Builder signieren Scope, Seiten, SEO-Erwartungen und Out of Scope ab.
2. Struktur und Wireframes. Information Architecture und Schlüssel-Templates vor visueller Politur vereinbart.
3. Design für Primär-Templates. Home plus eine Interior-Money-Page, bevor jede Seite designt wird.
4. Build und Content-Drop. Copy und Assets kommen an einem genannten Datum an – sonst rutscht die Timeline definitionsgemäß.
5. Staging-Review. Funktionale und Content-QA gegen die Acceptance-Liste.
6. Launch und Handoff. DNS, Analytics, Repo-Zugang und Dokumentation wie in Ownership definiert.

Einen Decision Owner für Design, Copy und technischen Go-Live benennen. Committees, die alle „approven“ und niemand entscheidet, verbrennen Ihre Timeline. Wenn Sie Founder sind, Ihren eigenen Namen für den finalen Call zu Brand und Messaging schreiben und nennen, wer Staging-Bugs day-to-day freigeben kann.

Jeder Meilenstein hat ein Datumsfenster und einen benannten Owner für den Call, der den nächsten Schritt freigibt.

Ownership von Accounts, Domains und Code

Dieser Abschnitt rettet Beziehungen. Bevor jemand startet, aufschreiben, wer besitzt:

• Domain-Registrar und DNS
• Hosting- oder Platform-Account (Vercel, Netlify, Cloudflare Pages, WP Engine usw.)
• Git-Repository
• CMS (falls vorhanden)
• Google Analytics / GA4 und Google Search Console
• E-Mail-Versand für Formulare (Resend, Formspree, Ihr ESP)
• Third-Party-Scripts (Chat, Ads, A/B-Tools)
• Design-Dateien (Figma)

Default-Regel, die für die meisten Founder funktioniert: Die Firma besitzt jeden Production-Account. Der Builder bekommt Collaborator-Zugang, nicht persönliches Eigentum an Domain oder Repo. Wenn ein Freelancer darauf besteht, die Domain „bis zur Schlusszahlung“ zu halten, ist das eine Verhandlungsflagge, keine Standardpraxis.

Auch aufschreiben, was beim Handoff passiert: Admin-Invites übertragen, persönliche Builder-Accounts entfernt, Deploy-Keys bei Bedarf rotiert und ein kurzes README, wie man eine Änderung ausliefert.

Firmen-eigene Accounts mit Builder-Zugang, nicht Builder-eigene Production-Keys.

Warnung: Lassen Sie Search Console oder Domain nach Launch nicht unter der privaten Gmail eines Contractors. Wenn die Beziehung endet, wird Recovery hässlich.

Out of Scope (der Abschnitt, der alle schützt)

Out of Scope ist keine Feindseligkeit. Es ist, wie Sie das Quote ehrlich halten. Listen Sie die Arbeit, die Sie in diesem Engagement nicht kaufen, auch wenn sie verwandt klingt.

Häufige Items für einen Marketing-Site-Brief:

• Custom Web App oder eingeloggte Produkt-UI
• Laufendes Content-Writing über eine vereinbarte Artikelzahl hinaus
• Linkbuilding oder Outreach
• Paid-Ads-Setup und -Management
• Brand Identity von null (Logo, volle Guidelines), sofern nicht gequoted
• Fotografie oder Videoproduktion
• Multilinguale Expansion über gelistete Locales hinaus
• Migrationen von E-Mail-Listen, CRM-Pipelines oder Billing-Systemen
• SLA-backed Uptime über den Host-Default hinaus

Wenn etwas später erscheinen könnte, unter „Phase-2-Kandidaten“ legen statt es mündlich in v1 zu schmuggeln. Builder, die zu unendlichem Scope nicken, liefern unter oder schicken Change Orders. Founder, die Out of Scope nicht aufschreiben, entdecken es meist als Überraschungsrechnungen.

Out-of-Scope-Items liegen außerhalb des v1-Zauns, damit Quotes vergleichbar und Change Orders absichtlich bleiben.

Acceptance Criteria, die sagen, wann die Site fertig ist

Acceptance ist die Checkliste auf Staging vor dem DNS-Flip. Ohne sie wird „fertig“ Geschmack. Mit ihr zählt Geschmack weiter für Design, aber Ship-blocking Issues sind objektiv.

Acceptance als Pass/Fail-Statements an den Brief binden:

• Jede Must-ship-Seite ist über Primärnavigation oder vereinbarten Sitemap-Pfad erreichbar.
• Jeder gelistete Flow läuft auf Desktop und Mid-Size-Phone durch (Formular submitet, Thank-you zeigt, Notification kommt an).
• Redirects aus der vereinbarten Map liefern das korrekte Ziel.
• Titles und H1s existieren für Primär-Templates und passen zum vereinbarten Copy Deck.
• Analytics feuert auf Key Events, die Sie gelistet haben (Formular-Submit, Outbound-Calendar-Click).
• Legal-Seiten im Footer sind vorhanden, wenn für Ihren Markt nötig.
• Kaputte Links und Console-Errors auf Primär-Templates sind geklärt oder explizit waived.
• Repo-, Hosting- und Analytics-Zugang entspricht dem Ownership-Abschnitt.

Design-Politur kann eine separate „bekannte Follow-ups“-Liste haben. Launch nicht für Pixel-Debatten geiseln, die nie im Brief standen, und kaputte Flows nicht überspringen, weil die Homepage gut aussieht.

Pass/Fail-Acceptance-Zeilen machen aus Staging-Review eine Ship-Entscheidung statt eines Geschmacksstreits.

Praxisbeispiel: B2B-SaaS-Founder briefet v1

Maya führt ein Series-A-Workflow-Tool. Sie braucht eine öffentliche Site vor einer Partner-Ankündigung in sechs Wochen. Sie ist versucht, „eine moderne Site wie Linear, plus Blog, plus Customer-Portal-Teaser“ zu verlangen.

Stattdessen füllt sie den Brief:

• Ziele. Partner-ready Product Story; Demo-Requests von Mid-Market-Ops-Leads; Search Console verbunden mit Redirects von den alten Webflow-Pfaden.
• Audience. Ops Manager, die dieses Quartal Tools evaluieren; Partner, die Integrations-Glaubwürdigkeit prüfen.
• Must-ship-Seiten. Home, Product, Integrations, Pricing, Security, About, Demo, Privacy, Terms. Blog-Index mit nur drei migrierten Posts.
• Flows. Demo-Formular zu HubSpot; Security-Seite aus Footer und Pricing-Fußnote verlinkt.
• SEO. Technische Baseline, Redirects von 14 alten URLs, kein neuer Content-Retainer in v1.
• Out of Scope. Customer-Portal-UI, Custom-Illustrations-Pack, Ads, laufende Blog-Produktion.
• Ownership. Firmen-Cloudflare und GitHub; Builder als Collaborator; Maya besitzt GA4 und Search Console.
• Acceptance. Flows auf Staging getestet; Redirect-Stichproben; Formular landet in der richtigen HubSpot-Pipeline.

Das Quote, das sie bekommt, ist über zwei Freelancer vergleichbar, weil beide denselben Zaun preisen. Wenn jemand in Woche drei einen Portal-Mock vorschlägt, zeigt sie auf Out of Scope und plant Phase 2 statt das Partner-Datum zu sprengen.

Mayas Brief zäunt partner-ready Seiten und Redirects ein und parkt das Portal in Phase 2.

Copy-Paste Website-Development-Brief-Vorlage

Nutzen Sie das als Working Doc. Guidance in Klammern löschen, während Sie Antworten füllen.

1. Projekt-Snapshot

• Arbeitstitel / Firmenname:
• Primäre Domain (aktuell und beabsichtigt):
• Ziel-Launch-Fenster:
• Decision Owner (finaler Call zu Scope und Go-Live):
• Day-to-day-Kontakt:

2. Ziele und Success-Signale

• Ziel 1 + wie wir es in 30–90 Tagen messen:
• Ziel 2 + wie wir es messen:
• Ziel 3 (optional):
• Was diese Site nicht lösen soll:

3. Audience und Jobs

Für bis zu drei Audiences:

• Wer sie sind:
• Job auf diesem Besuch:
• Beweis, der Risiko senkt:
• Primäre CTA, die wir von ihnen wollen:

4. Brand und Constraints

• Bestehende Brand Assets (Logo, Farben, Fonts, Figma):
• Ton-Notizen (maximal drei Adjektive plus ein „vermeiden“):
• Wettbewerber oder Referenz-Sites (was strukturell entlehnen, nicht kopieren):
• Accessibility- oder Compliance-Notizen (WCAG-Ziel, Branchen, Regionen):
• Sprachen / Locales in v1:

5. Sitemap und Flows

• Must-ship-Seiten:
• Should-ship, wenn Budget erlaubt:
• Explizit später / Phase 2:
• Kritische Flows (nummeriert):
• Bestehendes URL-Inventar angehängt? (ja/nein + Link):
• Redirect-Map-Owner:

6. Content und Assets

• Wer schreibt Copy:
• Copy-Freeze-Datum für Launch-Templates:
• Bild- / Videoquellen:
• Kundenquotes oder Logos zur Nutzung freigegeben:
• Erforderliche Legal-Seiten:

7. SEO und Measurement

• Technische SEO-Baseline erforderlich? (ja/nein)
• On-Page für welche Templates:
• Blog / Content in v1 (Anzahl oder keines):
• Redirects erforderlich? (ja/nein)
• Analytics-Tools und Event-Liste:
• Search-Console- und Analytics-Account-Owner:

8. Stack-Präferenzen (optional)

• Bevorzugtes Framework oder CMS (oder „Builder empfiehlt“):
• Hosting-Präferenz:
• Formular- / CRM-Ziel:
• Dinge, für die wir schon zahlen und die wiederverwendet werden müssen:

9. Meilensteine

Meilenstein	Zielfenster	Owner	Exit Criteria
Brief locked
IA / Wireframes
Design für Primär-Templates
Build + Content-Drop
Staging-Acceptance
Launch + Handoff

10. Ownership

Asset	Firmen-Owner-Account	Builder-Zugangslevel	Handoff-Notiz
Domain / DNS
Hosting
Git-Repo
CMS
Analytics
Search Console
Formulare / ESP
Design-Dateien

11. Out of Scope

• Items auflisten, die in diesem Quote nicht enthalten sind:
• Phase-2-Kandidaten (optional):

12. Acceptance Criteria

• Checkliste von Pass/Fail-Statements für Staging:
• Bekannte Follow-ups nach Launch erlaubt (non-blocking):
• Sign-off-Namen und Datum:

13. Kommerzielle Notizen (kurz halten)

• Fixed Fee oder Time-and-Materials:
• Was eine Change Order auslöst:
• Support-Fenster nach Launch (Tage Bugfix, falls vorhanden):

Das ist die nutzbare Vorlage. Alles darüber existiert, damit Sie diese Felder mit Absicht füllen statt mit leeren Überschriften.

Den Brief übergeben, ohne den Faden zu verlieren

Den Brief senden, bevor Sie ein finales Quote verlangen. Einmal live durchgehen, wenn der Builder neu für Sie ist, dann eine Version einfrieren (Datum im Dateinamen oder Shared-Doc-Versionshistorie). Änderungen nach Freeze werden Amendments. Das klingt formal für eine Fünf-Seiten-Site. Es ist, wie Sie vermeiden, zweimal für dieselbe Arbeitswoche zu zahlen.

Beim Vendor-Vergleich gegen denselben Brief scoren. Fragen, wo sie mit Ihrem Out of Scope oder SEO-Block uneinig sind. Uneinigkeit früh ist nützlich. Stille, die später zu „SEO war impliziert“ wird, nicht.

Nach Launch den Brief mit dem Handoff-README archivieren. Der nächste Contractor sollte keine Séance mit Ihrer Slack-Historie brauchen.

Eine datierte Brief-Version wandert vom Founder zum Builder vor dem finalen Quote und archiviert sich mit Handoff-Notizen.

Häufig gestellte Fragen

Wie lang sollte ein Website-Development-Brief sein?

Zwei bis fünf Seiten reichen für die meisten Marketing-Sites. Wenn Sie einen Roman brauchen, spezifizieren Sie wahrscheinlich eine Produktanwendung. Brief kurz halten und Inventare anhängen (URLs, Redirects, Copy Decks) statt jede Zeile in die Narrative zu stopfen.

Kann ich diesen Brief für Webflow, WordPress und Custom Code nutzen?

Ja. Der Brief ist absichtlich stack-agnostisch. Präferenzen in den Stack-Abschnitt legen, wenn Sie welche haben. Wenn nicht, den Builder bitten, einen Stack zu empfehlen, der zu Ownership und Update-Bedarf passt, dann die Wahl vor Build-Start zurück in den Brief schreiben.

Was, wenn ich meine Sitemap noch nicht kenne?

Das sagen und Discovery zu einem bezahlten Meilenstein mit klarem Exit machen: vorgeschlagene Sitemap und Flows, die Sie vor Visual Design freigeben. Keine Sicherheit vortäuschen, die Sie nicht haben. Fake-Sitemaps erzeugen Rework.

Sollten SEO und Development separate Briefs sein?

Für eine kleine Marketing-Site ist ein Brief mit ehrlichem SEO-Block meist besser. Wenn Sie ein großes Content-Programm, technische SEO-Remediation oder internationales Hreflang-Arbeit kaufen, können das separate Statements of Work sein, die von diesem Brief verlinkt werden, damit Ownership klar bleibt.

Wer sollte den Brief schreiben, Founder oder Agentur?

Der Founder (oder die Person, die Outcomes besitzt) sollte Ziele, Audience, Out of Scope und Ownership schreiben. Ein guter Builder kann Sitemap, Flows und Acceptance-Sprache mitfeilen. Wenn eine Agentur den gesamten Brief allein schreibt, lesen Sie ihn als ihr Sales-Dokument, bis Sie die Ziele in eigenen Worten editieren.

Was gehört in eine Change Order?

Alles, was Seiten, Flows, Integrationen, Locales oder Content-Volumen über den locked Brief hinaus hinzufügt oder ein Phase-2-Item in v1 zieht. Geschmacks-Tweaks innerhalb eines freigegebenen Templates meist nicht. Wenn unsicher, fragen: „Ändert das die Acceptance-Checkliste?“ Wenn ja, ist es ein Change-Order-Gespräch.

Die Schleife schließen, bevor Sie Stunden kaufen

Ein klarer Brief macht einen schwachen Builder nicht stark. Er macht starke Builder schneller, Quotes vergleichbar und Launch Day auf die Art langweilig, die Sie wollen. Vorlage füllen, Version einfrieren und Amendments als normal behandeln, wenn das Business etwas Neues lernt.

Wenn Sie Hilfe wollen, einen groben Brief in einen scoped Marketing-Site-Build zu verwandeln (Seiten, SEO-Baseline, Ownership und Acceptance inklusive), melden Sie sich über das Kontaktformular.