Every product we have ever shipped went through the same week.
The core app is working. Someone asks where the changelog is. Someone else wants a help center. Marketing needs a blog with tags and search. Legal needs a Terms page you can edit without a deploy. Sales wants a public roadmap. And every one of those is a database table, an editor, a public route, and a deploy pipeline that has nothing to do with the product you are actually building.
So you do what everyone does. You bolt on a headless CMS meant for magazines, or you wire up three SaaS tools that do not know about each other, or — most often — you write yet another posts table and promise yourself you will make it nice later.
The seven surfaces
Look at any mature SaaS product and you will find roughly the same set of content surfaces:
A blog, with tags, search and pagination
A changelog, with versions and release types
A help center, with categories and search
Static pages — Terms, Privacy, About
Announcements shown inside the app
Remote config and feature flags
Feedback and a public roadmap
None of these is hard. All of them together are a quarter of engineering time that never shows up on a roadmap, because each one arrives separately and each one looks small.
What Kookee is
Kookee is a content backend for developers. One project, one API key, all seven surfaces:
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: 'billing' });
const flag = await kookee.config.getByKey('feature-new-checkout');Your team writes in a real editor in the dashboard. Your app reads through a typed SDK. Nothing between them needs a deploy.
The three decisions that shaped it
Content is data, not pages. Kookee never renders your frontend. It returns JSON with an HTML body, and you decide what it looks like. That is the difference between a CMS that owns your design and a backend that stays out of the way. The hosted portal and the optional React components are there for teams who want them; the API itself stays headless.
TypeScript first, not TypeScript later. The SDK is zero-dependency and built on native fetch. Every module, parameter and response shape is typed, so a wrong method or parameter name is a compile error rather than a surprise in production.
One key, safe to ship. The API key only reads content you have already published, plus anonymous-safe actions like reactions. So it lives in a browser bundle — no signing dance, no proxy route you have to build before your first page works. Writing happens in the dashboard, or through an AI assistant connected with your own MCP token, which stays on your machine.
What it is not
Kookee is not a page builder, and it is not trying to become your application database. If your content is user-generated at scale, or it is the product itself, you want your own tables. Kookee is for the content around the product — the writing your team does that your users need to read.
Where to start
Install the SDK and let a coding assistant wire up the first surface. The types ship with the package, so the assistant writes against real method signatures instead of guessing at them:
npm install @kookee/sdkBuild a blog with the
@kookee/sdkpackage, which is already installed. A listing page with tag filtering and pagination, and a detail page with rendered HTML content.
Fifteen minutes later you have a working blog page and one less thing on the backlog. Then do the changelog. Then the help center. That is the whole idea.