Три вещи, которые я проверяю до любого headless-проекта

Первый вопрос, который я задаю до любого КП: «Кто будет редактировать контент после нас — и на чём?»

Если ответ — «Битрикс остаётся как CMS, редакторам ничего менять не надо», разговор продолжается. Если «ну, разберёмся» — это другой проект с другим бюджетом и другим таймлайном.

Три часа до старта экономят шесть недель в середине.

Я принял решение не подписывать контракт на $40k именно потому, что pre-flight занял один день — и выявил, что проект не был готов к headless не технически, а организационно. Полная история в «Я отказался от $40K-контракта». Но суть: не стек убивает headless-проекты. Убивает то, что их начинают без трёх конкретных проверок.

Эти три проверки не про «нужен ли вам headless вообще» — для этого есть отдельный разговор (см. «Пять вопросов, которые я задаю перед тем, как предложить headless»). Эти три — про то, что нужно сделать, когда решение уже принято и проект начинается.

Проверка №1: редакторы и CMS

Самый недооценённый вопрос: кто будет менять контент после запуска?

В headless-архитектуре Bitrix или Laravel остаётся бэкендом — CMS для редакторов. Фронт (Next.js) тянет данные через API. Если редакторы привыкли работать в Bitrix — отлично, ничего не меняется. Они входят в знакомый интерфейс, публикуют, и фронт автоматически обновляется.

Проблема начинается, когда в процессе выясняется, что редакторы «в принципе не работают с Bitrix» или «нам хотелось бы перейти на что-то другое заодно». Это означает: параллельная миграция CMS поверх headless-реструктуризации. Два изменения одновременно — два источника риска.

Три вопроса, которые стоит задать сразу:

Сколько человек редактирует контент сейчас?
Они остаются на текущей CMS или меняют инструмент?
Кто обучает редакторов новому workflow, если он меняется?

Если редактор один и он разработчик — окей, быстро адаптируется. Если редакторов пять и они маркетологи — это отдельный track внутри проекта с отдельным бюджетом на обучение.

Проверка №2: API-поверхность в День 1

Headless-архитектура работает через API. Фронт не рендерит страницы из CMS напрямую, а запрашивает данные по эндпоинтам. И если этот список не составить до старта, первый спринт уйдёт на его сборку в реальном времени.

В 28k SKU каталоге мы составили список ещё до старта разработки. Получилось 12 эндпоинтов только для главных потоков: листинг категорий, карточка товара, фильтры, поиск, корзина, checkout-данные. Без этого списка первые три недели ушли бы на выяснение того, что именно нужно фронтенду — и это в реальном времени, когда разработчики уже блокированы.

Для этого достаточно взять макеты всех экранов и для каждого выписать: какие данные нужны и откуда они берутся. API mapping. Занимает 2-3 часа на типовой e-com проект.

Если в этом списке появляются данные, которых в текущей CMS нет или они структурированы иначе — это ранний сигнал на доработку бэкенда. Лучше увидеть это в таблице на день 2, чем в логах на неделе 8.

Проверка №3: деплойный пайплайн

Headless означает разделённые деплои: фронт живёт отдельно от бэка. Это одно из главных преимуществ архитектуры — обновление Bitrix не трогает Next.js, и наоборот.

Но это преимущество работает только если инфраструктура под него подготовлена.

Есть ли CI/CD для фронта? (GitHub Actions, Vercel, GitLab CI — неважно, главное — автоматический деплой по пушу)
Бэкенд деплоится через FTP или через pipeline?
Есть ли staging, или только production?

Самый частый антипаттерн, который я встречаю: фронт на Next.js разрабатывают, но деплоить планируют «рядом с Bitrix» через FTP на тот же сервер. Это не headless. Это дорогой шаблон с API. Деплойный пайплайн — не деталь реализации, это фундамент архитектурного решения.

Если CI/CD нет, его нужно настроить до старта основной разработки. Занимает 1-2 дня. Если этого не сделать — команда начнёт деплоить вручную, потом забудет, потом окажется, что prod и staging расходятся.

Что делать с неудобными ответами

Три проверки дают один из трёх исходов:

Всё ок — стартуем с понятной базой, без скрытых рисков.
Есть gaps — фиксируем в проектном документе, оцениваем объём доработки, корректируем смету и таймлайн до подписания.
Критический блокер — рекомендую отложить headless-запуск и решить конкретную проблему сначала. Это неприятный разговор, но лучше на этапе pre-flight, чем через два месяца.

Только одно условие: клиент должен участвовать. Это не чеклист для разработчика в одиночестве. Редактор приходит с конкретными кейсами своей работы. Product owner объясняет, что за данные нужны на каждом экране. Devops показывает текущий деплойный процесс.

Без этого получается pre-flight на бумаге, а реальные блокеры появляются в процессе.

Три часа против шести недель

Эти три проверки занимают 1-3 часа в зависимости от сложности проекта. Идеальный старт они не гарантируют, но самые предсказуемые блокеры будут найдены до того, как деньги начнут расходоваться.

Headless — рабочая архитектура. Я её использую. Но она не работает сама по себе — только когда начинается с честного разговора о том, что есть сейчас.

Если на вашем проекте решение о headless уже принято, но эти три проверки ещё не сделаны — сделайте их до следующего спринта. Не после.