Beide Projekte hatten dieselbe Ausgangslage: ein gewachsenes Drupal und den Wunsch nach einem moderneren Frontend. Im einen Fall ging das gut. Im anderen entstand ein Wartungsaufwand, den am Ende niemand haben wollte, und die Entscheidung dafür war in beiden Fällen dieselbe gewesen.
Wo es getragen hat
Redaktion und Frontend waren zwei Teams mit eigenen Releasezyklen. Der Redaktion gehörte Drupal, dem Frontend alles hinter JSON:API, und dort konnte es tun, was es für richtig hielt.
Entscheidend war dabei weniger die Technik. Diese Grenze lag genau dort, wo die Organisation ohnehin schon geteilt war.
Wo es nicht getragen hat
Im zweiten Projekt pflegte genau eine Person beide Seiten. Sobald sich ein Content-Typ änderte, waren es plötzlich zwei Änderungen statt einer, und ohne Zusatzaufwand lief die Vorschau gar nicht mehr. Eingezogen hatten wir eine Grenze, die niemand brauchte. Bezahlt haben wir sie bei jeder einzelnen Änderung.
Headless löst kein technisches Problem. Es löst ein organisatorisches — und nur dann, wenn es das auch wirklich gibt.
Vorab frage ich deshalb nicht mehr „Passt die Technik?“, sondern „Gibt es zwei Teams, die sich sonst gegenseitig blockieren?“. Lautet die Antwort nein, bleibt das Frontend in Drupal. Und alle schlafen besser.