Headless CMS für dein Startup wählen: Payload vs Sanity vs Strapi

Die meisten Startups denken erst über ihr CMS nach, wenn sie einen Blogbeitrag veröffentlichen, eine Karriereseite starten oder Preistexte aktualisieren müssen — und merken, dass das bedeutet, einen Entwickler zu bitten, Code zu ändern und neu zu deployen. Das ist meist der Moment, in dem „wir sollten ein CMS haben” von einer netten Idee zu einer echten Entscheidung wird, und es lohnt sich, diese Entscheidung bewusst zu treffen, statt einfach zu nehmen, was der erste Blogbeitrag empfohlen hat.

Dieser Leitfaden erklärt, was ein Headless-CMS eigentlich ist, wann ein Startup wirklich eines braucht, und wie sich drei der gängigsten selbst hostbaren Optionen — Payload, Sanity und Strapi — in den Punkten unterscheiden, die für ein kleines Team zählen: Einrichtungsaufwand, Entwicklererfahrung und wofür sie tatsächlich gut geeignet sind.

Was ein Headless-CMS eigentlich ist

Ein traditionelles CMS wie WordPress bündelt zwei Dinge: einen Ort zum Speichern von Content und ein eingebautes Frontend, das ihn zu Seiten rendert. Das ist praktisch, solange eure App nicht auf dem Frontend von WordPress läuft — was auf fast jedes moderne Startup zutrifft, das ein Produkt mit React, Next.js, Astro oder einer mobilen App baut.

Ein Headless-CMS trennt diese beiden Aufgaben. Es speichert und verwaltet euren Content — Blogbeiträge, Landingpage-Texte, FAQs, Team-Bios, was auch immer — und stellt ihn über eine API bereit (meist REST oder GraphQL). Euer eigenes Frontend, gebaut in dem Stack, den euer Team bereits nutzt, holt diesen Content ab und rendert ihn, wie ihr wollt. Der „Kopf” (die Präsentationsschicht) gehört vollständig euch; das CMS kümmert sich nur um den „Körper” (Content-Speicherung und -Bearbeitung).

Das ist für Startups besonders wichtig, weil eure Marketingseite oder euer Blog dadurch dieselbe Designsprache und sogar denselben Code wie euer Kernprodukt teilen kann, statt auf einer angeflanschten WordPress-Instanz zu leben, die aussieht wie ein anderes Unternehmen.

Wann ein Startup tatsächlich eines braucht

Hier ist der Unterschied, der leicht übersehen wird: Die Kerndaten eures MVP — Nutzerkonten, Transaktionen, was eure App tatsächlich tut — gehören fast nie in ein CMS. Diese Daten haben ihre eigene Struktur, ihre eigenen Beziehungen und ihre eigenen Zugriffsmuster und sollten in der eigenen Datenbank eurer Anwendung leben, verwaltet über eure eigene API.

Ein Headless-CMS lohnt sich für eine engere, aber weiterhin reale Content-Kategorie:

• Eine Marketingseite oder Landingpages, die Textupdates ohne Deploy brauchen
• Ein Blog, wie dieser hier, den Gründer oder Marketer regelmäßig aktualisieren
• Ein Hilfecenter oder ein Dokumentationsbereich
• Eine Changelog- oder Release-Notes-Seite
• Karriereseiten, Case Studies oder Presseseiten

Wenn nichts davon noch zutrifft — ihr seid vor dem Launch, eure „Marketingseite” ist eine einzige Landingpage, und niemand außer einem Entwickler fasst sie an — braucht ihr wahrscheinlich noch kein CMS. Texte fest ins Frontend zu codieren ist schneller gebaut und völlig in Ordnung, bis die Update-Frequenz oder die Anzahl der nicht-technischen Personen, die Content bearbeiten müssen, groß genug wird, um das zusätzliche System zu rechtfertigen. Ein CMS zu früh hinzuzufügen ist selbst eine Form von Overengineering — dieselbe Falle, die in unserem Leitfaden zur Wahl des besten Tech-Stacks für ein MVP behandelt wird: Jedes zusätzliche System ist etwas, das euer Team betreiben, absichern und aktuell halten muss.

Die Hauptkandidaten: Payload, Sanity, Strapi

Es gibt Dutzende Headless-CMS-Produkte, aber drei tauchen in Gesprächen über den Tech-Stack von Startups immer wieder auf, weil sie Open Source oder selbst hostbar, entwicklerfreundlich sind und aktive Communities haben: Payload, Sanity und Strapi. Alle drei ermöglichen es einem kleinen Team, strukturierten Content aufzubauen, ohne ein Admin-Panel von Grund auf selbst zu bauen.

Payload CMS

Payload ist ein code-first, TypeScript-natives Headless-CMS, das ihr vollständig im Code konfiguriert — euer Content-Schema, Zugriffskontrolle und Hooks leben alle in eurer Codebasis statt in einem separaten visuellen Builder. Es läuft auf Node.js, integriert sich natürlich in eine Next.js- oder Express-App und generiert automatisch sowohl REST- als auch GraphQL-APIs aus euren Schema-Definitionen. Da alles im Code definiert ist, lässt es sich sauber zusammen mit dem Rest eurer Anwendung versionieren und passt gut zu einem Team, das bereits mit einem TypeScript-Monorepo vertraut ist.

Sanity

Sanity trennt Content-Speicherung (Sanitys eigener gehosteter „Content Lake”) von Content-Bearbeitung (Sanity Studio, eine anpassbare React-basierte Admin-Oberfläche) und Content-Auslieferung (dessen API). Sanity Studio ist schnell eingerichtet und für Nicht-Entwickler wirklich angenehm zu nutzen, sobald ein Entwickler das Schema aufgesetzt hat, was es zu einer starken Wahl macht, wenn euer Content-Team häufige, strukturierte Änderungen vornimmt — etwa ein Marketingteam, das mehrmals wöchentlich veröffentlicht. Der Kompromiss ist, dass euer Content in Sanitys gehosteter Infrastruktur liegt statt in einer Datenbank, die ihr vollständig kontrolliert, wodurch es standardmäßig weniger „selbst gehostet” ist als die anderen beiden.

Strapi

Strapi ist eines der am längsten laufenden Open-Source-Headless-CMS-Projekte und von Tag eins an vollständig auf eurer eigenen Infrastruktur selbst hostbar. Es kommt mit einem eingebauten Admin-Panel, einem Plugin-Ökosystem und sowohl REST- als auch GraphQL-Unterstützung von Haus aus. Strapi fühlt sich von den dreien am ehesten wie eine traditionelle CMS-Admin-Erfahrung an — ein visueller Content-Type-Builder plus ein browserbasiertes Dashboard — während Entwickler dennoch volle Kontrolle über Hosting und die zugrunde liegende Datenbank behalten.

Payload vs Sanity vs Strapi auf einen Blick

	Payload	Sanity	Strapi
Hosting-Modell	Selbst gehostet (Node.js-App, die ihr deployt); bietet auch Managed Hosting	Standardmäßig gehostete Content-Schicht (Sanity Content Lake)	Selbst gehostet (Node.js-App, die ihr deployt); bietet auch Managed Hosting
Entwicklererfahrung	Schema und Konfiguration vollständig im Code definiert (TypeScript-first), passt natürlich in ein bestehendes App-Repo	Schema im Code definiert, aber Bearbeitung erfolgt in einer separaten gehosteten Studio-App	Visueller Content-Type-Builder plus Code-Anpassung über Plugins
Am besten für	Teams, die bereits in einem TypeScript/Next.js-Stack arbeiten und das CMS neben der App-Codebasis haben wollen	Teams mit häufigen Content-Updates durch Nicht-Entwickler, die mit einer gehosteten Datenschicht vertraut sind	Teams, die ein selbst gehostetes, traditionell wirkendes Admin-Panel mit starker Plugin-Unterstützung wollen

Wie ihr tatsächlich wählt

Alle drei sind in unterschiedlichem Maße entwicklerorientierte Tools — keines davon ist ein Drag-and-Drop-Website-Baukasten, und jemand in eurem Team muss Code schreiben, um das Schema einzurichten und mit eurem Frontend zu verbinden. Die eigentliche Entscheidung läuft auf zwei Fragen hinaus.

Was kennt euer Team bereits?

Wenn eure Entwickler bereits tief in einem TypeScript- und Next.js-Stack stecken, fühlt sich Payload meist wie die natürlichste Erweiterung dieser Codebasis an statt wie ein separat angeflanschtes System. Wenn euer Team gewohnt ist, eigene Node.js-Dienste aufzusetzen und zu betreiben, und volle Kontrolle über das Hosting will, passt das selbst gehostete Modell von Strapi gut. Wenn ihr lieber keine weitere Backend-Infrastruktur verwaltet und mit einer gehosteten Content-Schicht einverstanden seid, nimmt Sanity euch diese operative Last ab. Das ist dieselbe „wählt nach dem, was euer Team tatsächlich umsetzen kann, nicht nach dem, was gerade angesagt ist”-Logik, die in unserem Framework zur Bewertung von Technologieempfehlungen, ohne sich täuschen zu lassen behandelt wird — das „beste” CMS ist das, das euer Team sicher betreiben und erweitern kann, nicht das mit den meisten GitHub-Sternen.

Wie wird Content tatsächlich erstellt?

Wenn Content-Updates hauptsächlich von Entwicklern oder einem einzelnen technischen Gründer kommen, funktionieren alle drei gut — die Unterschiede in der täglichen Bearbeitungserfahrung fallen dann weniger ins Gewicht. Wenn ein nicht-technischer Marketer oder Gründer regelmäßig veröffentlichen wird, gewichtet die Bearbeitungserfahrung stärker: Sanity Studio und das Admin-Panel von Strapi sind beide für dieses Publikum gebaut, während die Bearbeitungserfahrung von Payload, obwohl solide, eher Teams anspricht, die sie eng mit eigenem Frontend-Tooling kombinieren.

Es gibt auch eine Lizenz- und Kostendimension, die es sich zu prüfen lohnt, bevor ihr euch festlegt — Selbst-Hosting bedeutet, dass ihr die Infrastrukturkosten und Wartung selbst tragt, während eine gehostete Option das auf ein Abonnement verschiebt. Dieser Kompromiss spiegelt die breitere Open-Source-vs-Managed-Services-Entscheidung wider, die wir in unserem Leitfaden zu Open-Source- vs. proprietären Tools für euer MVP behandeln — prüft die aktuellen Preise und Lizenzen jeder Plattform direkt auf der offiziellen Payload-Website, der offiziellen Sanity-Website oder der offiziellen Strapi-Website, bevor ihr entscheidet, da sich Bedingungen und Kostenlos-Limits mit der Zeit ändern.

Lasst die CMS-Wahl nicht zum Flaschenhals werden

Egal, für welches der drei ihr euch entscheidet — das größte Risiko für die meisten frühen Teams ist nicht, das „falsche” CMS zu wählen, sondern Wochen mit der Bewertung von Optionen für eine Entscheidung zu verbringen, die später mit etwas Migrationsaufwand tatsächlich rückgängig gemacht werden kann. Wählt das, was zu den Fähigkeiten passt, die euer Team bereits hat, richtet es für eure Marketingseite oder euren Blog ein und kehrt zum Bauen und Validieren eures eigentlichen Produkts zurück.

Wenn ihr noch herausfindet, welche Teile eures Tech-Stacks diese sorgfältige Wahl verdienen und welche nicht, ist das genau die Art von Entscheidung, bei der euch ein erfahrener MVP-Entwicklungspartner schnell helfen kann, statt zu raten.

Häufig gestellte Fragen

Braucht mein MVP wirklich ein Headless-CMS?

Für das Kernprodukt selbst meist nicht — die nutzerorientierten Daten eurer App gehören fast immer in eure eigene Datenbank und API. Ein Headless-CMS lohnt sich, sobald ihr eine Marketingseite, einen Blog, ein Hilfecenter oder ein Changelog habt, das Nicht-Entwickler regelmäßig ohne Code-Deploy aktualisieren müssen.

Was ist der Unterschied zwischen einem Headless-CMS und einem traditionellen CMS wie WordPress?

Ein traditionelles CMS bündelt Content-Speicherung mit einem eingebauten Frontend, das Seiten für euch rendert. Ein Headless-CMS speichert und verwaltet Content nur und stellt ihn über eine API bereit, sodass ihr das Frontend in jedem Framework bauen könnt, das euer Team bereits nutzt — auch demselben, mit dem eure App läuft.

Ist Payload CMS kostenlos?

Payload ist Open Source und unter eigener Lizenz kostenlos selbst hostbar, bietet aber auch eine Managed-Hosting-Option, falls ihr die Infrastruktur nicht selbst betreiben möchtet. Prüft die offizielle Payload-Website für aktuelle Lizenz- und Preisinformationen, bevor ihr euch festlegt, da sich Bedingungen ändern können.

Was ist für einen nicht-technischen Gründer einfacher: Payload, Sanity oder Strapi?

Alle drei sind entwicklerorientierte Tools, für deren Einrichtung des Content-Schemas und die Anbindung an ein Frontend jemand mit Code-Erfahrung nötig ist. Sanitys gehostetes Studio ist in der Regel am schnellsten, um ein kleines Team nach der Ersteinrichtung produktiv Content erstellen zu lassen, während Payload und Strapi im Alltag stärker auf eure eigenen Entwickler setzen.

Kann ich später die Headless-CMS-Plattform wechseln, wenn ich meine erste Wahl überwachse?

Ja, aber das erfordert echte Migrationsarbeit — Content exportieren, Schemas neu abbilden und Frontend-Abfragen gegen die neue API neu aufbauen. Es lohnt sich, von Anfang an bewusst anhand der Fähigkeiten eures Teams und der Content-Anforderungen zu wählen, statt willkürlich zu entscheiden und anzunehmen, ein Wechsel sei später schmerzlos.