Warum ich Kookee gebaut habe

Product

Jedes Produkt, das ich je ausgeliefert habe, hat dieselbe Woche durchgemacht.

Die eigentliche App läuft. Jemand fragt, wo der Changelog ist. Jemand anderes will ein Hilfecenter. Das Marketing braucht einen Blog mit Tags und Suche. Die Rechtsabteilung braucht eine AGB-Seite, die man ohne Deploy ändern kann. Der Vertrieb will eine öffentliche Roadmap. Und jedes davon ist eine Datenbanktabelle, ein Editor, eine öffentliche Route und eine Deploy-Pipeline, die nichts mit dem Produkt zu tun haben, an dem du eigentlich baust.

Also machst du, was alle machen. Du schraubst ein Headless-CMS an, das für Magazine gedacht ist, oder du verkabelst drei SaaS-Tools, die nichts voneinander wissen, oder du legst – und das ist der häufigste Fall – noch eine posts-Tabelle an und nimmst dir vor, sie später schön zu machen.

Die sieben Bereiche

Schau dir ein beliebiges ausgereiftes SaaS-Produkt an, und du findest ungefähr dieselben Content-Bereiche:

  • Ein Blog mit Tags, Suche und Paginierung

  • Ein Changelog mit Versionen und Release-Typen

  • Ein Hilfecenter mit Kategorien und Suche

  • Statische Seiten: AGB, Datenschutz, Über uns

  • Ankündigungen, die in der App erscheinen

  • Remote-Config und Feature-Flags

  • Feedback und eine öffentliche Roadmap

Keiner davon ist schwer. Zusammen kosten sie aber ein Viertel der Entwicklungszeit, und das taucht auf keiner Roadmap auf, weil jeder Bereich einzeln kommt und jeder klein aussieht.

Was Kookee ist

Kookee ist ein Content-Backend für Entwickler. Ein Projekt, ein API-Schlüssel, alle sieben Bereiche:

TypeScript
import { Kookee } from '@kookee/sdk';

const kookee = new Kookee({ apiKey: process.env.KOOKEE_API_KEY! });

const posts = await kookee.blog.list({ limit: 10 });
const releases = await kookee.changelog.list({ filter: { changelogType: 'feature' } });
const articles = await kookee.help.search({ query: 'Abrechnung' });
const flag = await kookee.config.getByKey('feature-new-checkout');

Dein Team schreibt in einem richtigen Editor im Dashboard. Deine App liest über ein typisiertes SDK. Dazwischen braucht nichts einen Deploy.

Drei Entscheidungen, die Kookee geprägt haben

Inhalte sind Daten, keine Seiten. Kookee rendert nie dein Frontend. Es liefert JSON mit einem HTML-Body, und du entscheidest, wie das aussieht. Das ist der Unterschied zwischen einem CMS, das über dein Design bestimmt, und einem Backend, das dir nicht im Weg steht. Das gehostete Portal und die optionalen React-Komponenten gibt es für Teams, die sie wollen. Die API selbst bleibt headless.

TypeScript von Anfang an, nicht irgendwann. Das SDK hat keine Abhängigkeiten und baut auf dem nativen fetch auf. Jedes Modul, jeder Parameter und jede Antwortstruktur ist typisiert. Ein falscher Methoden- oder Parametername wird so zum Compilerfehler statt zur Überraschung in Produktion.

Ein Schlüssel, den du ausliefern kannst. Der API-Schlüssel liest nur Inhalte, die du schon veröffentlicht hast, dazu Aktionen, die auch anonym unbedenklich sind, etwa Reaktionen. Deshalb kann er im Browser-Bundle liegen: kein Signatur-Tanz, keine Proxy-Route, die du bauen musst, bevor deine erste Seite funktioniert. Geschrieben wird im Dashboard oder über einen KI-Assistenten, den du mit deinem eigenen MCP-Token verbindest. Das Token bleibt auf deinem Rechner.

Was Kookee nicht ist

Kookee ist kein Page-Builder und will auch nicht die Datenbank deiner Anwendung werden. Wenn deine Inhalte in großem Umfang von Nutzern erzeugt werden oder selbst das Produkt sind, brauchst du eigene Tabellen. Kookee ist für die Inhalte rund um das Produkt da: für das, was dein Team schreibt und deine Nutzer lesen müssen.

Wo du anfängst

Installier das SDK und lass einen Coding-Assistenten den ersten Bereich anbinden. Die Typen kommen mit dem Paket, also schreibt der Assistent gegen echte Methodensignaturen, statt sie zu raten:

Bash
npm install @kookee/sdk

Bau einen Blog mit dem Paket @kookee/sdk, das schon installiert ist. Eine Listenseite mit Tag-Filter und Paginierung und eine Detailseite mit gerendertem HTML-Inhalt.

Eine Viertelstunde später hast du eine funktionierende Blogseite und einen Punkt weniger im Backlog. Dann kommt der Changelog dran. Dann das Hilfecenter. Das ist die ganze Idee.