„Ist doch nur ein Blog, den bauen wir in einem Sprint“: Dieser Satz fällt früher oder später in jedem Engineering-Channel eines SaaS-Teams, und halbwegs stimmt er sogar. Eine Tabelle für Beiträge, ein paar Routen, ein Markdown-Feld: ein Sprint. Was diese Schätzung übersieht, ist alles, was der Sprint-Version fehlt, und alles, was die Jahre nach dem Sprint kosten. Ich habe genau diesen Stack gebaut, und Kookee gibt es, weil ich finde, dass die meisten Teams das nicht tun sollten. Hier ist die ehrliche Rechnung.
Was aus „nur einem Blog“ tatsächlich wird
Die Sprint-Version hat keinen Editor, der den Namen verdient, also wächst das Projekt sofort:
Der Editor. Das Marketing schreibt keine Markdown-Dateien hinter einem Pull Request. Ein echter Rich-Text-Editor mit Bildern, Embeds, Codeblöcken und einem Undo, das funktioniert, kostet Wochen, selbst wenn du ein Open-Source-Editor-Framework einbindest, und danach braucht er dauerhaft Pflege.
Medienverwaltung. Uploads, Speicher, Bildskalierung, ein CDN-Pfad, Größenlimits. Jedes Content-System bekommt so etwas irgendwann, deins auch.
Workflow. Entwürfe, geplantes Veröffentlichen, Vorschau-Links und eine Versionshistorie, um die jemand betteln wird, sobald ein Redakteur zum ersten Mal eine Stunde Arbeit überschreibt.
Die Felder rund um den Inhalt. Slugs und ihre Eindeutigkeit, Tags, Kategorien, SEO-Metadaten, Open-Graph-Bilder, Zeitstempel.
Dann kommt die zweite Oberfläche. Ein Changelog braucht Typen und Versionen, ein Hilfecenter Kategorien und eine Suche, Feedback braucht Abstimmungen, Status und Kommentare. Jedes davon ist „klein“, jedes baut Erstellen, Speichern und Ausliefern mit einer eigenen Besonderheit noch einmal, und jedes wird zu einem weiteren internen Produkt, das nur du pflegst.
Vorsichtig geschätzt brauchen Blog, Changelog und Hilfecenter mit einer brauchbaren Admin-Oberfläche Monate an Entwicklungszeit, nicht Sprints. Zu den üblichen Vollkosten für Entwickler ist das echtes Geld, bevor ein einziger Nutzer eine Seite sieht, und es ist der günstige Teil.
Der Posten, den alle vergessen: für immer
Die Schätzung für den Eigenbau endet beim Launch. Das System nicht:
Sicherheit und Abhängigkeiten. Dein Content-System ist jetzt Angriffsfläche (Auth, Uploads, eine öffentliche API), die du nach deinem eigenen Zeitplan patchst, für immer. Dependency-Updates, Framework-Migrationen, die nächste Major-Version der Editor-Bibliothek mit Breaking Changes: Abgaben, die jedes Jahr fällig werden.
Infrastruktur. Hosting, Datenbank, Object Storage, CDN, Monitoring, Backups. Einzeln klein, zusammen eine laufende Rechnung und eine laufende Rufbereitschaft.
Die Feature-Tretmühle. Eine Suche, die Dinge wirklich findet (heute heißt das semantische Suche und Embeddings), Übersetzungen, wenn du ins Ausland expandierst, KI-Antworten, sobald die Hilfecenter der Konkurrenz welche haben. Jedes davon ist ein Projekt auf einem System, das niemand verantworten will.
Die Wartung eines selbst gebauten Content-Stacks dürfte einige Wochen Entwicklungszeit pro Jahr kosten, unauffällig verteilt auf „schnelle Fixes“, die nie schnell sind. Schwerer wiegen die Opportunitätskosten: Jede Stunde dort fehlt beim Produkt, für das Kunden bezahlen. Content-Infrastruktur ist Standardware, dein Produkt nicht. Knappe Entwicklungszeit in die Standardware zu stecken ist der eigentliche Fehler, unabhängig von der Rechnung.
Gründe, trotzdem selbst zu bauen
Texte zu „Bauen oder kaufen“, die dem Eigenbau nie recht geben, sind Werbung. Es gibt echte Gründe zu bauen:
Inhalte sind dein Produkt. Bist du eine Publishing-Plattform oder ein Doku-Anbieter, oder unterscheidest du dich gerade durch deine Content-Workflows, dann bau selbst. Ein Standardwerkzeug wird gegen dich arbeiten.
Harte Vorgaben. Regulierte Umgebungen, in denen Inhalte in deiner Infrastruktur liegen müssen, Air-Gapped-Deployments, Vorgaben zur Datenresidenz, die ein Anbieter nicht erfüllen kann.
Wirklich ungewöhnliche Modelle. Wenn deine Inhalte tatsächlich nicht wie Einträge mit Feldern aussehen. Prüf aber vorher, ob eigene Eintragstypen auf einer Plattform das abdecken.
Nicht stichhaltig ist dagegen: „Wir bauen genau das, was wir brauchen, nicht mehr.“ Die Liste oben ist kein aufgeblähter Funktionsumfang eines Anbieters. Darauf läuft jedes Content-System hinaus, weil Redakteure, Marketing und Leser immer wieder nach denselben Dingen fragen.
Was du beim Kaufen wirklich bekommen solltest
Wenn du kaufst, miss den Anbieter an dem Maßstab, der den Verzicht aufs Bauen rechtfertigt:
Deine Domain und dein Frontend. Die Inhalte kommen als JSON über eine API und ein SDK und werden von deiner App mit deinem Designsystem gerendert. So landet der SEO-Effekt bei dir, und nichts wirkt angeflanscht. Besteht der Anbieter darauf, deine Seiten zu hosten, hast du einen Website-Baukasten gekauft und keine Infrastruktur.
Kein Lock-in. Alles lässt sich mit deinem API-Schlüssel als dokumentiertes JSON abrufen. Gerade weil die Tür nach draußen offen steht, ist der Einstieg sicher.
Alles in einem System. Blog, Changelog, Hilfecenter, Feedback, Seiten: Der Nutzen wächst, wenn das Feedback-Board auf den Changelog-Eintrag verlinkt und das Hilfecenter die KI-Antworten speist, mit einem Dashboard und einer API statt vier zusammengestückelter Anbieter, deren Abos zusammen ohnehin oft mehr kosten als eine einzige Plattform.
Ein kostenloser Einstieg. Du solltest die Integration testen können, bevor du irgendetwas bezahlst.
Nach diesem Maßstab ist Kookee gebaut: ein Content-Backend mit den Modulen, die SaaS-Produkte tatsächlich brauchen, ein typisiertes SDK und React-Hooks für die Rendering-Schicht, ein gehostetes Portal für den ersten Tag und Auslieferung nach dem API-first-Prinzip. Der einzige Code, der dir gehört, ist der dünne Teil, der schon immer deiner war: das Rendering.
Ein Entscheidungsverfahren
Sind Inhalte das, was dich unterscheidet, oder greift eine harte Vorgabe? Wenn ja, bau selbst, bewusst und mit den Leuten, die es braucht.
Wenn nicht, bau einen Prototyp für den Kaufweg: Render deine Blog-Liste und einen Hilfeartikel über das SDK einer Plattform auf deiner Domain. Plan dafür einen Tag ein.
Rechne den Eigenbau ehrlich durch: die ersten Monate plus die jährliche Wartung zu Vollkosten, gegen das Abo.
Entscheide einmal, schriftlich, und hör auf, die Frage jedes Mal neu aufzurollen, wenn jemand sagt: „Ist doch nur ein Blog.“
Den Blog im Sprint-Format gibt es wirklich, du kannst ihn bis Freitag haben. Mit dem Kaufpreis vergleichst du aber die fünf Jahre nach diesem Freitag.