Каждый продукт, который я выпускал, проходил через одну и ту же неделю.
Основное приложение работает. Кто-то спрашивает, где журнал изменений. Кому-то нужен центр помощи. Маркетингу нужен блог с тегами и поиском. Юристам нужна страница с условиями использования, которую можно править без деплоя. Продажам нужна публичная дорожная карта. И каждая из этих просьб — это таблица в базе, редактор, публичный маршрут и пайплайн деплоя, которые не имеют никакого отношения к продукту, над которым вы работаете.
Поэтому вы делаете то же, что и все. Прикручиваете headless CMS, рассчитанную на онлайн-издания, или связываете три SaaS-сервиса, которые ничего не знают друг о друге, или — чаще всего — пишете очередную таблицу posts и обещаете себе потом сделать её по-человечески.
Семь разделов
Посмотрите на любой зрелый SaaS-продукт, и вы найдёте примерно один и тот же набор разделов с контентом:
Блог с тегами, поиском и пагинацией
Журнал изменений с версиями и типами релизов
Центр помощи с категориями и поиском
Статические страницы — условия использования, политика конфиденциальности, «О нас»
Объявления внутри приложения
Удалённая конфигурация и фича-флаги
Обратная связь и публичная дорожная карта
Ни один из них не сложен. Но вместе они съедают четверть времени разработки, и это время никогда не попадает в дорожную карту, потому что каждый раздел появляется отдельно и каждый выглядит мелочью.
Что такое Kookee
Kookee — бэкенд контента для разработчиков. Один проект, один API-ключ, все семь разделов:
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');Ваша команда пишет в полноценном редакторе в панели управления. Ваше приложение читает данные через типизированный SDK. Между ними нет ничего, что требовало бы деплоя.
Три решения, на которых он построен
Контент — это данные, а не страницы. Kookee никогда не рендерит ваш фронтенд. Он возвращает JSON с телом в HTML, а как это выглядит, решаете вы. В этом разница между CMS, которая диктует вам дизайн, и бэкендом, который не мешает. Готовый портал и необязательные React-компоненты есть для команд, которым они нужны, а сам API остаётся headless.
Сразу TypeScript, а не TypeScript когда-нибудь потом. SDK не тянет зависимостей и построен на нативном fetch. Все модули, параметры и структуры ответов типизированы, поэтому неправильное имя метода или параметра — это ошибка компиляции, а не сюрприз в продакшене.
Один ключ, который не страшно отдать в браузер. API-ключ читает только уже опубликованный контент и выполняет безопасные анонимные действия вроде реакций. Поэтому он живёт в браузерном бандле: никаких плясок с подписью запросов, никакого прокси-маршрута, который нужно написать до того, как заработает первая страница. Пишут контент в панели управления или через ИИ-ассистента, подключённого вашим собственным MCP-токеном, а токен остаётся на вашем компьютере.
Для чего Kookee не подходит
Kookee — не конструктор страниц, и он не пытается стать базой данных вашего приложения. Если ваш контент массово создают пользователи или он сам и есть продукт, вам нужны собственные таблицы. Kookee — для контента вокруг продукта: текстов, которые пишет ваша команда и которые нужно прочитать вашим пользователям.
С чего начать
Установите SDK и поручите ИИ-ассистенту для кода подключить первый раздел. Типы идут вместе с пакетом, поэтому ассистент пишет код под настоящие сигнатуры методов, а не угадывает их:
npm install @kookee/sdkСделайте блог на пакете
@kookee/sdk, он уже установлен. Страница списка с фильтром по тегам и пагинацией и страница поста с отрендеренным HTML.
Через пятнадцать минут у вас готова страница блога, а в бэклоге на одну задачу меньше. Потом журнал изменений. Потом центр помощи. Вот и вся идея.