Freie Hand für die Entwicklung: Warum Headless Dev-Teams schneller macht

Kurzantwort: In einem monolithischen CMS arbeitet die Entwicklung gegen das System: eigene Templating-Sprache, Plugins mit unklarer Zukunft, Updates, die Code brechen. In einem Headless Content Hub liefert das CMS Inhalte über eine dokumentierte API, und das Frontend entsteht mit den Werkzeugen, die das Team ohnehin beherrscht. In Flyo-Kundenprojekten sank der Aufwand für neue Webseiten so um 56 %.

Was der Monolith Entwickler:innen kostet

Drei Muster kennt fast jedes Dev-Team, das länger mit WordPress, TYPO3 oder einem ähnlichen System arbeitet:

• Eine eigene Welt. Jedes System hat seine Templating-Sprache, seine Hooks und seine Eigenheiten. Wer neu ins Team kommt, lernt zuerst das CMS und erst dann das Projekt.
• Plugins als Hypothek. Viele Funktionen kommen über Erweiterungen von Dritten. Jedes Update stellt die Frage, welche davon überleben, und jede nicht mehr gepflegte Erweiterung wird zum eigenen Projekt.
• Gegenseitiges Blockieren. Die Redaktion wartet auf Templates, die Entwicklung wartet auf Inhalte. Bis dahin füllt Lorem ipsum die Seiten, und Layoutprobleme zeigen sich erst mit echten Texten.

Was sich mit Headless ändert

In einem Headless Content Hub ist das CMS nicht mehr Teil der Website, sondern eine eigene Ebene, die Inhalte als Daten liefert. Für die Entwicklung heisst das:

• Frameworks frei wählbar. Vue, Nuxt, Astro, Next.js, Laravel oder reines PHP: Das Team baut mit dem Stack, den es kennt.
• Ein maschinenlesbarer Vertrag. Flyo liefert Inhalte über eine REST-API mit vollständiger OpenAPI-Spezifikation. Im Nitro CMS erhält zudem jede Komponente eine eigene OpenAPI-Deklaration. Welche Felder es gibt und welche Typen sie haben, ist dokumentiert statt mündlich überliefert.
• Vorschau ist Ergebnis. Die Live-Vorschau im Editor läuft über dieselbe API wie die produktive Website. Was die Redaktion sieht, geht genau so live.
• Parallel mit echten Inhalten. Weil Inhalte unabhängig vom Frontend existieren, arbeiten Redaktion und Entwicklung gleichzeitig. Bei der AHA Aeschbachhalle hiess das: kein Warten auf fertige Bausteine, kein Lorem ipsum.
• Kein CMS-Betrieb. Flyo läuft als gehosteter Dienst. Updates, Sicherheit und Hosting des Content Hubs liegen nicht beim Dev-Team.

Ein Beispiel: Basel Editions

Wie weit das gehen kann, zeigt das Projekt Basel Editions. StadtKonzeptBasel brachte drei Printmagazine ins Web und entwickelte die Komponenten selbst, unterstützt von Claude Code. Flyo stellte das technische Setup, automatisierte Tests und das Code-Review.

Weil das Datenmodell vor der ersten Komponente stand und jede Komponente gegen ihre OpenAPI-Deklaration gebaut wurde, entstand in wenigen Wochen ein wartbarer Auftritt, ohne Inhaltsmigration.

Und um fair zu bleiben

Headless nimmt der Entwicklung die Arbeit nicht ab, es verlagert sie dorthin, wo sie hingehört. Das Frontend ist echte Entwicklungsarbeit und braucht ein eigenes Deployment. Das Inhaltsmodell will durchdacht sein, bevor der erste Code entsteht. Und wer selbst keine Entwicklungsressourcen hat, braucht eine Agentur oder einen Partner, der das Frontend baut.

Fazit

Drei Dinge entscheiden, ob Headless für ein Dev-Team zur Erleichterung wird:

1. Das Datenmodell zuerst. Inhaltstypen, Felder und Beziehungen stehen, bevor die erste Komponente entsteht.
2. Komponenten statt Seiten. Jede Einheit hat eine klare Aufgabe und eine klare Schnittstelle zu den Inhalten. Das hält Änderungen lokal und macht Wiederverwendung möglich.
3. Das Review entscheidet über die Architektur. Tests fangen das Offensichtliche ab. Ob der Code an der richtigen Stelle sitzt, beurteilen Menschen.

Mehr zur Schnittstelle auf der Produktseite zur API ↗, zum Umstieg auf der Lösungsseite Monolith ablösen ↗.