Eine moderne Web-Entwicklungs-RFP schreiben: Ein Leitfaden für 2026

Ich war auf beiden Seiten des RFP-Prozesses. Als Entwickler habe ich RFPs erhalten, die so vage waren, dass ich überall zwischen $15K und $150K hätte anbieten können und beides wäre ehrlich gewesen. Als Agentur habe ich Clients geholfen, ihre RFPs umzuschreiben, nachdem die erste Runde Angebote mit wildly unterschiedlichen Vorschlägen zurückkam. Das Problem ist nicht, dass Agenturen versuchen, dich abzuzocken. Es ist, dass die meisten RFPs zu viel Raum für Interpretation lassen.

Wenn du einen Website-Relaunch 2026 mit modernen Tools wie Next.js, Astro oder einem Headless CMS planst, muss deine RFP die Sprache dieses Stacks sprechen. Eine generische RFP-Vorlage von 2019 wird nicht ausreichen. Du musst deine technischen Anforderungen so kommunizieren, dass qualifizierte Agenturen dir genaue, vergleichbare Angebote machen können. Und wenn du bereit bist, voranzugehen, reiche deine RFP bei einem Team ein, das diese Tools täglich einsetzt.

Dieser Leitfaden führt dich durch jeden Abschnitt einer modernen Web-Entwicklungs-RFP mit spezifischer Anleitung für Headless-Architektur-Projekte. Ich habe am Ende eine herunterladbare Vorlagenstruktur eingefügt.

Inhaltsverzeichnis

Warum die meisten Web-Entwicklungs-RFPs scheitern

Lass mich direkt sein: Der typische RFP-Prozess ist kaputt, weil er für die falschen Dinge optimiert. Die meisten Vorlagen, die du online findest, wurden für traditionelle WordPress- oder Enterprise-CMS-Projekte entworfen. Sie konzentrieren sich auf Funktionschecklisten und Seitenzahlen, was einer Agentur fast nichts über die tatsächliche Projektkomplexität sagt.

Hier ist, was schiefgeht:

Zu vage bei der technischen Ausrichtung. Zu sagen "wir wollen eine moderne, schnelle Website" hilft nicht. Eine Agentur, die WordPress mit einem Page Builder erstellt, und eine Agentur, die mit Astro mit einem Headless CMS erstellt, lösen grundlegend unterschiedliche Probleme. Wenn du deine technischen Vorlieben nicht spezifizierst, wirst du Angebote mit völlig unterschiedlichen Architekturen erhalten.

Keine Erwähnung des Content-Workflows. Es ist überraschend, wie viele RFPs das Frontend im Detail beschreiben, aber nichts darüber sagen, wie Inhalte erstellt, überprüft und veröffentlicht werden. Bei Headless-CMS-Projekten ist die redaktionelle Erfahrung ein Kern-Deliverable.

Unrealistische Timelines an echte Komplexität angeklebt. Ich habe RFPs gesehen, die um eine Headless-Commerce-Plattform mit Personalisierung, Multi-Sprachen-Unterstützung und einem Design-System mit einem 6-Wochen-Zeitplan bitten. Agenturen gehen entweder weg oder polstern ihr Angebot mit genug Puffer, um den unvermeidlichen Scope-Creep zu absorbieren.

Kein Budget-Bereich. Ich weiß, ich weiß. Du willst die Preisgestaltung nicht "verankern". Aber hier ist die Realität: Wenn du keinen Budget-Bereich eingeben kannst, verschwendest du die Zeit aller. Ein $30K-Projekt und ein $300K-Projekt können die gleiche Funktionsliste haben. Der Unterschied liegt in der Tiefe der Ausführung, des Testens, der Barrierefreiheit und der laufenden Unterstützung.

Was bei RFPs für Headless-Architektur anders ist

Traditionelle Website-RFPs gehen von einer monolithischen Architektur aus: Ein System behandelt Content-Management, Rendering, Hosting und Delivery. Wenn du zu einem Headless-Setup wechselst, bei dem dein CMS von deinem Frontend getrennt ist, muss die RFP mehrere zusätzliche Dimensionen behandeln.

Der Stack Matters Mehr

In einer monolithischen Welt gibt "baue uns eine WordPress-Site" einer Agentur 80% des technischen Kontexts, den sie braucht. In der Headless-Welt multiplizieren sich die Stack-Wahlmöglichkeiten:

Entscheidung Optionen zum Spezifizieren Warum es wichtig ist
Frontend-Framework Next.js, Astro, Remix, SvelteKit Beeinflusst SSR-Strategie, Build-Zeiten, Hosting-Kosten
Headless CMS Sanity, Contentful, Storyblok, Strapi, Payload Beeinflusst Content-Modellierung, Preisgestaltung, redaktionelle UX
Hosting/Bereitstellung Vercel, Netlify, Cloudflare Pages, AWS Beeinflusst CI/CD, Preview-Deployments, Kosten
API-Schicht REST, GraphQL, tRPC Beeinflusst Data-Fetching-Muster und Caching
Media-Verwaltung CMS-nativ, Cloudinary, imgix Beeinflusst Bildoptimierung und CDN-Kosten

Deine RFP sollte entweder deine Vorlieben spezifizieren oder ausdrücklich angeben, dass du für die Empfehlung der Agentur offen bist, und sie bitten, ihre Wahlmöglichkeiten zu begründen.

Content-Modellierung ist ein Deliverable

Bei einem traditionellen CMS sind Content-Typen oft vordefiniert durch die Plattform oder das Theme. Bei einem Headless CMS ist Content-Modellierung eine Design-Übung. Deine RFP muss deine Content-Typen, ihre Beziehungen und wie Editoren mit ihnen interagieren, beschreiben. Dies allein ist leicht 15-20% des gesamten Projektaufwands bei einem Headless-Build.

Preview- und Publishing-Workflows

Wir treffen dies mindestens einmal pro Quartal: Ein Client startet eine Headless-Site und das redaktionelle Team kann den Inhalt vor der Veröffentlichung nicht in der Vorschau anzeigen. Es sabotiert die Akzeptanz. Bei monolithischen CMSes ist Preview eingebaut. Bei Headless-Setups erfordert es benutzerdefinierte Implementierung. Deine RFP sollte deine Erwartungen hier spezifizieren. Brauchst du Echtzeit-Visual-Editing? Geplante Veröffentlichung? Multi-Environment-Previews?

RFP-Abbau Abschnitt für Abschnitt

Gehen wir jeden Abschnitt durch, den deine RFP enthalten sollte. Ich werde spezifisch sein, was man schreiben soll und was man weglässt.

1. Zusammenfassung der Geschäftsführung

Halte das auf einer Seite. Einschließlich:

  • Name deiner Organisation und was du tust (2-3 Sätze)
  • Warum du umgestaltest (sei ehrlich. "Unsere Site ist langsam" ist nützlicher als "wir wollen unsere digitale Präsenz verbessern")
  • Was Erfolg in konkreten Begriffen aussieht (schnellere Ladezeiten, höhere Konversion, leichtere Content-Verwaltung)
  • Deine Zeitbeschränkungen und alle Hard Deadlines (Produktstarts, Events, Geschäftsjahrgrenzen)

2. Bewertung des aktuellen Zustands

Hier sind die meisten RFPs zu dünn. Sei spezifisch:

## Aktueller Zustand
- Plattform: WordPress 6.4 auf WP Engine
- Monatlicher Traffic: ~120K Sessions (Google Analytics)
- Seitenzahl: ~340 Seiten über 12 Content-Typen
- Aktuelle Core Web Vitals: LCP 4.2s, CLS 0.18, INP 380ms
- Bekannte Probleme: Mobile-Erfahrung ist schlecht, Content-Editoren 
  verbringen ~3 Stunden pro Blog-Post aufgrund von Formatierungsproblemen,
  die Site-Suche gibt irrelevante Ergebnisse zurück
- Integrationen: HubSpot (Forms + CRM), Stripe (Zahlungen), 
  Algolia (Suche), Google Tag Manager

Je konkreter du hier bist, desto genauer werden die Angebote. Wenn du Google Analytics Screenshots oder einen Core Web Vitals Bericht teilen kannst, um so besser.

3. Projektumfang und Anforderungen

Unterteile dies in funktionale Anforderungen und nicht-funktionale Anforderungen.

Funktionale Anforderungen beschreiben, was die Site tun muss:

  • Benötigte Seitentypen und Templates
  • Navigationsstruktur
  • Such-Funktionalität
  • Formulare und Lead-Erfassung
  • E-Commerce oder Zahlungsabwicklung
  • Benutzer-Authentifizierung
  • Personalisierung oder A/B-Tests
  • Multi-Sprachen-Unterstützung

Nicht-funktionale Anforderungen beschreiben, wie es funktionieren muss:

  • Ziel-Core Web Vitals Scores (sei spezifisch: "LCP unter 2.5s auf 4G")
  • Barrierefreiheits-Standard (WCAG 2.2 AA ist das Minimum 2026)
  • Browser- und Geräte-Support-Matrix
  • Uptime-Anforderungen
  • Sicherheitsanforderungen (SOC 2, GDPR, etc.)

Wenn du diese RFP direkt schreibst und Feedback vor dem Versand möchtest, sende uns deine RFP und wir geben dir ehrliche Eingaben, ob sie bereit ist.

4. Design-Anforderungen

Sei klar, was du bereitstellst vs. was du brauchst:

  • Hast du ein bestehendes Brand/Design System?
  • Stellst du Figma-Mockups zur Verfügung oder muss die Agentur Design handhaben?
  • Brauchst du eine Komponentenbibliothek/Design-System als Deliverable?
  • Wie ist deine Haltung zu Design-Iterationen? Wie viele Revisionsrunden?

5. Content-Anforderungen

Dieser Abschnitt ist kritisch für Headless-Projekte:

  • Wer ist verantwortlich für Content-Migration? (Du, die Agentur oder gemeinsam?)
  • Wie viele Content-Typen existieren? Listet sie auf.
  • Wie viel Content-Volumen wird in den nächsten 2 Jahren erwartet?
  • Brauchst du strukturierten Inhalt, der über Kanäle wiederverwendet werden kann?
  • Wie sieht dein redaktionelles Team aus? (2 Personen? 20?)

Technische Anforderungen für Next.js- und Astro-Projekte

Wenn du dich bereits für dein Frontend-Framework entschieden hast oder zu einem neigst, hier ist, was du in deine RFP für die zwei beliebtesten Optionen 2026 einschließen solltest.

Next.js Spezifische Anforderungen

Next.js (derzeit Version 15) ist der Standard für dynamische, interaktive Web-Anwendungen. Wenn deine Site Authentifizierung, Echtzeit-Daten oder hohe Interaktivität braucht, schaust du wahrscheinlich auf Next.js.

Schließe diese in deine RFP ein:

## Technische Anforderungen: Next.js
- Server Components vs. Client Components Strategie
- Rendering-Ansatz: SSG, SSR, ISR oder hybrid (pro Seitentyp spezifizieren)
- App Router Implementierung (nicht Pages Router)
- React Server Components für Data Fetching
- Middleware-Anforderungen (Geo-Routing, A/B-Tests, Auth)
- Bildoptimierungs-Ansatz (next/image + externer Service)
- Bereitstellungsziel: Vercel, selbst gehostet oder andere
- Erwartete Build-Zeiten für vollständigen Site-Rebuild
- Inkrementelle Adoption-Strategie falls Migration von bestehender React-App

Wenn du verstehen möchtest, wie ein moderner Next.js-Build in der Praxis aussieht, hat unser Next.js-Entwicklungs-Team Fallstudien mit echten Performance-Benchmarks veröffentlicht.

Astro Spezifische Anforderungen

Astro ist zur Standard-Wahl für inhaltsreiche Sites geworden, die nicht viel Client-seitige Interaktivität brauchen. Marketing-Sites, Dokumentation, Blogs, Portfolio-Sites. Das ist sein Sweet Spot. Astro 5, veröffentlicht in spätem 2024, führte Content Layer und Server Islands ein, was es noch fähiger macht.

## Technische Anforderungen: Astro
- Content Collections Konfiguration und Schema
- Island-Architektur-Strategie (welche Komponenten brauchen Hydration?)
- Integration-Anforderungen (React, Svelte, Vue Islands?)
- View Transitions Implementierung
- Content Layer API Nutzung mit Headless CMS
- Statischer vs. hybrider Rendering-Modus
- Bereitstellungsziel: Cloudflare Pages, Netlify, Vercel oder andere
- Build-Zeit-Ziele für vollständige Site-Generierung

Astro-Projekte haben tendenziell einfachere Infrastruktur, erfordern aber durchdachte Entscheidungen, wo Interaktivität hinzugefügt wird. Wenn du an diesem Ansatz interessiert bist, arbeitet unsere Astro-Entwicklungs-Praxis seit v2 an Content-Sites mit Astro.

Framework-Vergleich für deine RFP

Faktor Next.js Astro
Am besten für Dynamische Apps, Dashboards, E-Commerce Content-Sites, Marketing, Docs
JS versendet an Client Mehr (hängt von Architektur ab) Minimal (nur Islands)
Build-Zeiten (500 Seiten) 45-90s (ISR reduziert dies) 20-45s
Hosting-Kosten (typisch) $20-200/mo auf Vercel $0-50/mo auf Cloudflare/Netlify
Lernkurve für Editoren Moderat Niedriger
Real-Time-Preview-Unterstützung Excellent (Draft Mode) Gut (mit Middleware)
Ökosystem-Reife Sehr reif Reif, wächst schnell

Headless-CMS-Anforderungen zum Einschließen

Die CMS-Entscheidung beeinflusst dein Projekt mehr, als die meisten Leute denken. Es geht nicht nur darum, wo Inhalt lebt. Es geht darum, wie die tägliche Editing-Erfahrung deines Teams für Jahre aussieht.

Hier ist, was du in deine RFP spezifizieren solltest:

Content-Modellierung

## Content-Modellierungs-Anforderungen
- Blog-Beiträge mit Kategorien, Tags, Autor-Profilen und verwandten Beiträgen
- Landing Pages mit modularen, umordenbaren Abschnitten (Hero, Features, 
  Testimonials, CTA-Blöcke)
- Team-Mitglied-Profile verlinkt zu Case Studies und Blog-Beiträgen
- Case Studies mit strukturierten Daten (Client, Industrie, Ergebnis-Metriken)
- Global-Einstellungen (Navigation, Footer, SEO-Standards)
- Wiederverwendbare Content-Blöcke (CTAs, Banner) über Seiten hinweg geteilt

Editorial Experience Anforderungen

Sei spezifisch über das, was dein Content-Team braucht:

  • Visual/WYSIWYG-Editing oder strukturiertes Feld-basiertes Editing?
  • Echtzeit-Zusammenarbeit (mehrere Editoren arbeiten gleichzeitig)?
  • Genehmigungsprozesse (Entwurf → Überprüfung → Veröffentlicht)?
  • Geplante Veröffentlichung?
  • Content-Versionierung und Rollback?
  • Asset-Verwaltung (Bilder, Videos, Dokumente)?
  • Rollenbasierte Zugriffskontrolle?

CMS-Plattform-Vergleich

CMS Preisgestaltung (2026) Am besten für Bemerkenswerte Stärke
Sanity Kostenlos, dann $99-$949/mo Komplexe Content-Modelle, Entwickler GROQ Abfragen, Echtzeit-Zusammenarbeit
Contentful Kostenlos, dann $300+/mo Enterprise, Multi-Team Reife API, Marketplace
Storyblok Kostenlos, dann €106+/mo Visual Editing, Marketing-Teams Visual Editor, Komponenten-basiert
Payload CMS Kostenlos (selbst gehostet), Cloud-Pläne verfügbar Volle Kontrolle, Next.js nativ Code-First, selbst-hostbar
Strapi Kostenlos (selbst gehostet), Cloud ab $29/mo Budget-bewusst, Open Source Flexibilität, große Community

Für tiefere Anleitung zur Auswahl und Implementierung eines Headless CMS, schau dir unsere Headless-CMS-Entwicklungs-Services an.

Budget, Timeline und Bewertungskriterien

Realistische Budget-Festlegung

Hier ist, was Headless-Website-Projekte 2026 tatsächlich kosten:

Projekttyp Typischer Budget-Bereich Timeline
Marketing-Site (10-30 Seiten) $25K - $75K 6-12 Wochen
Inhaltsreiche Site (100+ Seiten, Blog, Ressourcen) $50K - $150K 10-18 Wochen
E-Commerce (Headless, <1000 SKUs) $75K - $250K 12-24 Wochen
Enterprise-Plattform (Multi-Site, Personalisierung) $150K - $500K+ 16-32 Wochen

Schließe einen Budget-Bereich in deine RFP ein. Im Gegensatz. Sagen "unser Budget ist $60K-$90K" filtert sofort Agenturen aus, die $200K angeboten hätten und hilft realistischen Agenturen, das richtige Team zuzuordnen.

Wenn du eine schnelle Referenz brauchst, was verschiedene Engagement-Level kosten, halten wir unsere Preisseite transparent.

Timeline-Anleitung

Schließe diese Timeline-Details ein:

  • RFP-Antwort-Deadline
  • Entscheidungsdatum
  • Bevorzugtes Kickoff-Datum
  • Alle Hard-Launch-Deadlines und warum
  • Deine Verfügbarkeit für Feedback und Genehmigungen

Sei ehrlich über die Bandbreite deines Teams. Wenn deine Stakeholder nur alle zwei Wochen Designs überprüfen können, sag es. Das beeinflusst die Timeline mehr als die meisten technischen Entscheidungen.

Bewertungskriterien

Teile den Agenturen mit, wie du Angebote bewerten wirst. Hier ist ein Framework:

## Bewertungskriterien
1. Technischer Ansatz und Architektur (30%)
2. Relevantes Portfolio/Fallstudien (25%)
3. Team-Zusammensetzung und Verfügbarkeit (15%)
4. Timeline und Projektmanagement-Ansatz (15%)
5. Kosten (15%)

Beachte, dass Kosten nicht das Top-Kriterium sind. Wenn du rein auf Preis kaufst, wirst du bekommen, wofür du zahlst.

Häufige RFP-Fehler, die dich Geld kosten

Jede Feature je auflisten. Ich habe 40-seitige RFPs gesehen, die Anforderungen wie "Site sollte schnell laden" und "Design sollte modern sein" enthalten. Konzentriere dich auf die Spezifika. Wenn es nicht messbar oder einzigartig für dein Projekt ist, lass es aus.

Deine aktuellen Analytics nicht teilen. Agenturen können keine realistische Migrationsstrategie vorschlagen, ohne deine aktuellen Traffic-Muster, Top-Seiten und User-Flows zu verstehen. Teile deine Google Analytics-Daten unter NDA, wenn nötig.

Einen festen Gebotsumfang bei vagem Umfang zu benötigen. Feste Gebote funktionieren, wenn der Umfang kristallklar ist. Wenn du noch deine IA oder Content-Modellierung herausfindest, biete einen phasierten Ansatz an: fester Gebotsumfang für Discovery, dann ein verfeinertes Schätzungsumfang für den Build.

Post-Launch ignorieren. Deine RFP sollte spezifizieren, was nach Launch passiert. Brauchst du laufende Unterstützung? Content-Training? Performance-Überwachung? Ein Retainer für iterative Verbesserungen? Diese Kosten sind real und sollten Teil des Angebots sein.

An zu viele Agenturen senden. Deine RFP an 15 Agenturen zu senden garantiert, dass die besten nicht antworten werden. Sie wissen, dass die Chancen gegen sie stehen, und es lohnt sich nicht. An 3-5 qualifizierte Agenturen maximal senden.

RFP-Vorlagenstruktur

Hier ist eine Copy-Paste-bereite Gliederung für deine RFP:

# Website-Entwicklungs-RFP: [Dein Unternehmensname]
## Ausgestellt: [Datum]
## Antwort-Deadline: [Datum]

---

## 1. Zusammenfassung der Geschäftsführung
- Über [Unternehmen]
- Projektziele (3-5 Punkte)
- Erfolgskennzahlen

## 2. Aktueller Zustand
- Aktuelle Plattform und Hosting
- Traffic- und Performance-Daten
- Bekannte Schmerzpunkte
- Aktuelle Integrationen

## 3. Projektumfang
### 3.1 Funktionale Anforderungen
- [Seitentypen, Features, Integrationen auflisten]
### 3.2 Nicht-funktionale Anforderungen  
- Performance-Ziele (Core Web Vitals)
- Barrierefreiheit (WCAG 2.2 AA)
- Sicherheit und Compliance
- Browser-/Geräte-Support

## 4. Technische Vorlieben
- Frontend: [Next.js / Astro / Offen für Empfehlung]
- CMS: [Sanity / Contentful / Offen für Empfehlung]
- Hosting: [Vercel / Cloudflare / Offen für Empfehlung]
- Must-Have-Integrationen: [Auflisten]

## 5. Design-Anforderungen
- Bestehende Brand-Assets: [Ja/Nein, Link zu Brand-Guide]
- Erwartete Design-Deliverables: [Figma, Design-System, etc.]
- Revisionsprozess und Runden

## 6. Content-Anforderungen
- Content-Typen: [Mit Beschreibungen auflisten]
- Content-Migration: [Wer handhaben es?]
- Editorial-Workflow-Anforderungen
- Multi-Language: [Ja/Nein, welche Sprachen?]

## 7. Budget und Timeline
- Budget-Bereich: $[X] - $[Y]
- Ziel-Launch-Datum: [Datum]
- Key Milestones oder Hard Deadlines

## 8. Post-Launch-Anforderungen
- Training-Anforderungen
- Erwartete laufende Support-Anforderungen
- Hosting-Verwaltung

## 9. Bewertungskriterien
- [Mit Gewichtungen auflisten]

## 10. Einreichungs-Anforderungen
- Format und Längen-Erwartungen
- Erforderliche Abschnitte im Angebot
- Kontakt für Fragen
- Deadline und Einreichungsmethode

## 11. Anhänge
- Aktuelle Site-Analytics-Zusammenfassung
- Content-Bestandsaufnahme (falls verfügbar)
- Technisches Architektur-Diagramm (falls verfügbar)
- Brand-Guidelines (falls verfügbar)

Gerne passe dies an deine Anforderungen an. Das Wichtigste ist, wo es zählt spezifisch zu sein und ehrlich über das zu sein, was du noch nicht weißt.

Wenn du bereit bist, den RFP-Prozess zu überspringen und direkt mit Entwicklern zu sprechen, die diese Tools täglich einsetzen, kontaktiere uns. Wir helfen gerne, das Projekt zu umfassen, bevor du sogar die RFP schreibst.

FAQ

Wie lang sollte eine Website-Entwicklungs-RFP sein?

Ziele für 8-15 Seiten. Alles Kürzere fehlt wahrscheinlich die Details, die Agenturen brauchen. Alles Längeres und du schließt wahrscheinlich unnötige Füller ein. Die obige Vorlage läuft etwa 10 Seiten, wenn richtig ausgefüllt. Konzentriere dich auf Spezifika: messbare Anforderungen, konkrete technische Vorlieben und echte Daten über deine aktuelle Site.

Sollte ich Next.js oder Astro in meiner RFP spezifizieren oder offen lassen?

Wenn du eine starke Vorliebe oder bestehende Team-Expertise hast, spezifiziere es. Wenn du genuinely offen bist, sag es, aber bitte Agenturen, ihre Empfehlung zu begründen. Der schlechteste Ansatz ist, es vage zu lassen und dann enttäuscht zu sein, wenn die Hälfte der Angebote auf einem Framework sind, den du nicht wolltest. Eine Vorliebe setzen, sogar eine weiche wie "wir neigen zu Astro aus Performance-Gründen", gibt Agenturen nützliches Signal.

Muss ich einen Budget-Bereich in meine RFP einschließen?

Ja. Absolut. Ich weiß, dass es sich kontraintuitiv anfühlt, aber ein Budget-Bereich einschließen wird tatsächlich bessere Angebote. Ohne einen Bereich bieten Agenturen entweder niedrig an, um zu gewinnen, oder schlagen ihre Dream-Architektur vor, die 3x deinem Budget ist. Ein Bereich wie "$50K-$80K" teilt Agenturen genau mit, welches Niveau der Ausführung du erwartest. Die besten Agenturen werden nicht das Minimum anbieten. Sie zeigen dir, was sie in deinem Bereich liefern können.

Was ist die typische Timeline für ein Headless-CMS-Website-Projekt?

Für eine Marketing-Site mit 20-50 Seiten, erwarte 8-14 Wochen vom Kickoff bis zum Launch. Inhaltsreiche Sites mit 100+ Seiten, komplexen Content-Modellen und mehreren Integrationen dauern typischerweise 14-22 Wochen. Die größte Timeline-Variable ist nicht Entwicklung. Es sind Stakeholder-Feedback-Zyklen und Content-Migration. Baue einen Puffer für die ein.

Wie viele Agenturen sollte ich meine RFP an senden?

Drei bis fünf ist der Sweet Spot. Weniger als drei gibt dir nicht genug Vergleich. Mehr als fünf und du kreierst einen Viehmarkt, den Top-Agenturen ignorieren werden. Forsche im Voraus: überprüfe Portfolios, überprüfe Fallstudien und überprüfe, dass sie tatsächlich Projekte mit deinem bevorzugten Tech-Stack aufgebaut haben, bevor du die RFP sendest.

Was ist der Unterschied zwischen einem Headless CMS und einem traditionellen CMS für RFP-Zwecke?

Bei einem traditionellen CMS wie WordPress behandelt das CMS sowohl Content-Management als auch Page-Rendering. Deine RFP kann sich hauptsächlich auf Features und Design konzentrieren. Bei einem Headless CMS sind das Content-System und das Frontend separate Anwendungen, die sich via API unterhalten. Deine RFP muss beide Systeme unabhängig behandeln: die CMS-Konfiguration, Content-Modellierung, redaktionelle Workflows, UND das Frontend-Framework, Rendering-Strategie, Hosting und wie sie sich verbinden. Es ist im Grunde zwei Projekte in einem.

Sollte ich um ein Festpreisgebot oder Zeit-und-Material bitten?

Es hängt von deiner Umfangs-Klarheit ab. Wenn deine Anforderungen gut definiert sind und sich wahrscheinlich nicht ändern (selten, aber es passiert), Festpreis gibt dir Budget-Sicherheit. Wenn du noch erkundest oder erwartest, dass sich das Projekt entwickelt, Zeit-und-Material mit einem Budget-Cap ist ehrlicher. Viele Agenturen 2026 bevorzugen ein Hybrid: Festpreis für Discovery und Design, dann T&M für Entwicklung mit wöchentlicher Budget-Verfolgung. Frage Agenturen, welches Modell sie empfehlen und warum.

Welche Post-Launch-Unterstützung sollte ich in meine RFP einschließen?

Mindestens spezifiziere eine Garantieperiode (30-90 Tage für Bugfixes), Training für dein Content-Team, Dokumentation für das technische Setup und Hosting-/Monitoring-Erwartungen. Idealerweise schließe auch einen monatlichen Retainer für laufende Verbesserungen ein. Headless-Sites profitieren enorm von iterativer Performance-Optimierung und Content-Modell-Verfeinerungen in den ersten 6 Monaten nach Launch. Wenn du deine Anforderungen kartiert hast und schnell vorangehen möchtest, bekomme ein Angebot in 48 Stunden von unserem Team.