Por qué construí Kookee

Product

Todos los productos que he lanzado han pasado por la misma semana.

La aplicación principal ya funciona. Alguien pregunta dónde está el registro de cambios. Otra persona quiere un centro de ayuda. Marketing necesita un blog con etiquetas y búsqueda. Legal necesita una página de Términos que se pueda editar sin desplegar. Ventas quiere una hoja de ruta pública. Y cada una de esas cosas es una tabla en la base de datos, un editor, una ruta pública y un pipeline de despliegue que no tienen nada que ver con el producto que de verdad estás construyendo.

Así que haces lo que hace todo el mundo. Añades a la fuerza un CMS headless pensado para revistas, o conectas tres herramientas SaaS que no saben nada unas de otras, o, lo más habitual, escribes otra tabla posts más y te prometes que ya la pulirás más adelante.

Las siete secciones

Fíjate en cualquier producto SaaS maduro y encontrarás más o menos las mismas secciones de contenido:

  • Un blog, con etiquetas, búsqueda y paginación

  • Un registro de cambios, con versiones y tipos de lanzamiento

  • Un centro de ayuda, con categorías y búsqueda

  • Páginas estáticas: Términos, Privacidad, Acerca de

  • Anuncios que se muestran dentro de la app

  • Configuración remota y feature flags

  • Comentarios y una hoja de ruta pública

Ninguna es difícil. Todas juntas suponen una cuarta parte del tiempo de ingeniería que nunca aparece en ninguna hoja de ruta, porque cada una llega por separado y cada una parece pequeña.

Qué es Kookee

Kookee es un backend de contenido para desarrolladores. Un proyecto, una clave de API, las siete secciones:

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: 'billing' });
const flag = await kookee.config.getByKey('feature-new-checkout');

Tu equipo escribe en un editor de verdad en el panel. Tu app lee a través de un SDK tipado. Nada entre ambos necesita un despliegue.

Las tres decisiones que le dieron forma

El contenido son datos, no páginas. Kookee nunca renderiza tu frontend. Devuelve JSON con el cuerpo en HTML, y tú decides cómo se ve. Esa es la diferencia entre un CMS que se adueña de tu diseño y un backend que no se mete en medio. El portal alojado y los componentes de React opcionales están para los equipos que los quieran; la API en sí sigue siendo headless.

TypeScript desde el principio, no más adelante. El SDK no tiene dependencias y se basa en el fetch nativo. Cada módulo, parámetro y forma de respuesta tiene tipos, así que un nombre de método o de parámetro equivocado es un error de compilación y no una sorpresa en producción.

Una sola clave, segura en el cliente. La clave de API solo lee el contenido ya publicado, y lo único que escribe son acciones anónimas inofensivas, como las reacciones. Por eso puede ir en el bundle del navegador: sin firmas que gestionar ni una ruta proxy que tengas que montar antes de que funcione tu primera página. Se escribe en el panel, o desde un asistente de IA conectado con tu propio token MCP, que se queda en tu equipo.

Lo que no es

Kookee no es un constructor de páginas, ni pretende convertirse en la base de datos de tu aplicación. Si tu contenido lo generan los usuarios a gran escala, o si es el producto en sí, necesitas tus propias tablas. Kookee es para el contenido alrededor del producto: lo que escribe tu equipo y tus usuarios necesitan leer.

Por dónde empezar

Instala el SDK y deja que un asistente de programación monte la primera sección. Los tipos vienen con el paquete, así que el asistente escribe el código a partir de las firmas reales de los métodos, sin adivinarlas:

Bash
npm install @kookee/sdk

Crea un blog con el paquete @kookee/sdk, que ya está instalado. Una página de listado con filtro por etiquetas y paginación, y una página de detalle con el contenido HTML renderizado.

Quince minutos después tienes una página de blog que funciona y una tarea menos en el backlog. Luego el registro de cambios. Luego el centro de ayuda. Esa es toda la idea.