Todo produto que eu já lancei passou pela mesma semana.
O app principal está funcionando. Alguém pergunta onde está o registro de alterações. Outra pessoa quer uma central de ajuda. O marketing precisa de um blog com tags e busca. O jurídico precisa de uma página de Termos que dê para editar sem deploy. Vendas quer um roteiro público. E cada uma dessas coisas é uma tabela no banco de dados, um editor, uma rota pública e um pipeline de deploy que não têm nada a ver com o produto que você está construindo de fato.
Então você faz o que todo mundo faz. Acopla um CMS headless pensado para revistas, ou conecta três ferramentas SaaS que não conversam entre si, ou, o que é mais comum, escreve mais uma tabela posts e promete a si mesmo que vai deixá-la bonita depois.
As sete seções
Olhe qualquer produto SaaS maduro e você vai encontrar mais ou menos o mesmo conjunto de seções de conteúdo:
Um blog, com tags, busca e paginação
Um registro de alterações, com versões e tipos de mudança
Uma central de ajuda, com categorias e busca
Páginas estáticas: Termos, Privacidade, Sobre
Anúncios exibidos dentro do app
Configuração remota e feature flags
Feedback e um roteiro público
Nenhuma delas é difícil. Todas juntas somam um quarto do tempo de engenharia, e esse tempo nunca aparece no planejamento, porque cada uma chega separada e cada uma parece pequena.
O que é o Kookee
O Kookee é um backend de conteúdo para desenvolvedores. Um projeto, uma chave de API, as sete seções:
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');A sua equipe escreve num editor de verdade, no painel. O seu app lê por um SDK tipado. Nada entre os dois precisa de deploy.
As três decisões que deram forma ao Kookee
Conteúdo é dado, não página. O Kookee nunca renderiza o seu frontend. Ele devolve JSON com o corpo em HTML, e você decide a aparência. Essa é a diferença entre um CMS que toma conta do seu design e um backend que não se mete nele. O portal hospedado e os componentes React opcionais existem para as equipes que os querem; a API em si continua headless.
TypeScript desde o início, não depois. O SDK não tem dependências e usa o fetch nativo. Cada módulo, parâmetro e formato de resposta é tipado, então um nome errado de método ou de parâmetro vira erro de compilação, e não uma surpresa em produção.
Uma chave que pode ir para o navegador. A chave de API só lê o conteúdo que você já publicou, além de ações seguras para visitantes anônimos, como as reações. Por isso ela pode ficar no bundle do navegador: sem malabarismo para assinar requisições, sem uma rota de proxy que você precise montar antes de a primeira página funcionar. A escrita acontece no painel ou por um assistente de IA conectado com o seu próprio token MCP, que fica na sua máquina.
O que o Kookee não é
O Kookee não é um construtor de páginas e não pretende virar o banco de dados da sua aplicação. Se o seu conteúdo é gerado por usuários em grande escala, ou se ele é o próprio produto, você precisa das suas próprias tabelas. O Kookee é para o conteúdo em volta do produto: o que a sua equipe escreve e os seus usuários precisam ler.
Por onde começar
Instale o SDK e deixe um assistente de programação montar a primeira seção. Os tipos vêm com o pacote, então o assistente escreve com base nas assinaturas reais dos métodos, em vez de adivinhá-las:
npm install @kookee/sdkCrie um blog com o pacote
@kookee/sdk, que já está instalado. Uma página de listagem com filtro por tags e paginação, e uma página de detalhe com o conteúdo HTML renderizado.
Quinze minutos depois, você tem uma página de blog funcionando e uma tarefa a menos no backlog. Depois, faça o registro de alterações. Depois, a central de ajuda. A ideia é essa.