Как я объясняю headless клиенту: не про технологии, а про деньги
Клиент спрашивает: «Зачем нам headless, если Bitrix и так работает?»
У меня есть три ответа. Два из них — технические. Они почти никогда не работают. Один — про деньги. Он закрывает разговор в большинстве случаев.
Расскажу, почему так получается.
Почему «независимость деплоя» — мёртвая фраза
Я провёл этот разговор больше двадцати раз. Первые несколько раз я честно объяснял: «headless — это независимость деплоя, у вас фронт на Next.js, бэк на Bitrix, вы можете катить их независимо друг от друга».
Клиент кивает. И ничего не происходит.
Потому что «независимость деплоя» — это про мою боль, не про его. Он не понимает, почему это важно, пока у него не упал фронт из-за Bitrix-патча безопасности. А это случится только после того, как он уже принял решение — в ту или другую сторону.
Технические аргументы работают с людьми, которые уже понимают проблему. Клиент на пресейле её не чувствует.
Что клиент слышит на самом деле
Когда вы говорите «headless», клиент слышит: дорого, сложно, долго.
Нормальная реакция. Bitrix у него работает. Продажи идут. Зачем платить за то, что не сломано?
Ответ на этот вопрос не технический. Он финансовый.
Покажите ему, сколько стоит текущая ситуация — не в терминах «техдолга», а в деньгах и времени. Тогда разговор сдвинется.
Аргумент 1: сколько стоит следующая фича
На монолитном Bitrix-проекте типичная новая фича в каталоге или поиске проходит через один деплой. Фронтенд и бэкенд вместе. Один цикл тестирования, одно окно согласования.
На headless-проекте с 28 000 SKU, который мы строили, Next.js деплоился за 3 минуты. Bitrix — за 40. Но дело не в этом.
Главное — что 80% пользовательских фич живут во фронте. Новый блок на странице товара, изменение фильтров, A/B-тест баннера. Всё это Next.js-разработчик катит сам. Без согласования с PHP-командой. Без риска задеть бизнес-логику.
Если фронтенд-фича стоит 8 часов разработки, в монолите добавьте 4-6 часов на интеграцию, тестирование бэкенда и итерацию. На 10 фич в квартал это 40-60 лишних часов. По любой ставке это считаемые деньги.
Покажите клиенту эту цифру. Конкретную, из его темпа разработки.
Аргумент 2: сколько стоит следующий редизайн
Это самый сильный аргумент. Особенно если клиент уже думает о редизайне через год-два — именно этот расчёт я делал, когда отказывался от $40K-контракта на переписку.
В Bitrix-монолите редизайн — это замена шаблонов, компонентов, переработка верстки, которая переплетена с PHP-логикой. Типичный редизайн среднего интернет-магазина: 3-4 месяца, 15-25k евро, плюс регрессионное тестирование всего, что можно было задеть.
На headless-проекте редизайн — это только Next.js. Bitrix не трогаем. API-контракт не меняется. Данные те же. Тестирование в разы меньше.
По проектам студии: редизайн headless-фронта занимает примерно в 2.5-3 раза меньше времени, чем аналогичный в монолите. Это первый редизайн, который клиент заказывает после внедрения headless.
Инвестиция в headless-архитектуру окупается на первом редизайне. Иногда раньше.
Аргумент 3: зависимость от подрядчика
Это неочевидный, но очень работающий аргумент для клиентов, которые уже меняли разработчиков.
Монолитный Bitrix сильно зависит от стиля разработки конкретной команды. Нестандартные компоненты, специфические шаблоны, недокументированные хуки. Новый подрядчик въезжает 2-4 недели только в архитектуру.
Headless снижает эту зависимость. Next.js — стандарт де-факто. PHP API-слой в Bitrix — документируемый контракт. Если клиент захочет поменять фронтенд-команду, это не потребует полного погружения в CMS.
Спросите клиента: «Если вы захотите поменять подрядчика через два года, сколько времени займёт переезд?» Он примерно знает ответ. Подскажите ему, как headless этот ответ меняет.
Когда я говорю «вам headless не нужен»
Самый неожиданный момент для клиента.
Я говорю это примерно в трети случаев. Когда команда небольшая и не готова поддерживать два деплоя. Когда проект не меняется годами. Когда фронтенд и бэкенд на 100% синхронны по темпу разработки.
В такой ситуации headless добавит сложность без денежного выигрыша. Подробнее про признаки, когда headless — плохая идея писал отдельно.
Клиент, которому сказали «вам это не нужно», доверяет следующей рекомендации несравнимо больше. Это не альтруизм. Это работающая механика пресейла.
Шаблон разговора
Если хотите попробовать этот подход, вот как я строю разговор:
Сначала — вопрос: «Как часто у вас выходят новые фичи на сайт? Кто это делает?»
Потом — цифра: «Посчитаем, сколько из этих часов идёт на согласование между командами, а не на саму разработку?»
Потом — следующий горизонт: «Вы думаете о редизайне? Через год, через два?»
И уже после этого — архитектурный разговор. Но к тому моменту клиент уже не защищается. Он считает.
Технологии — следствие. Деньги — причина. Начинайте с причины.
Если узнаёте эту ситуацию и хотите посмотреть, как выглядит конкретный пресейл-разговор на живом проекте — напишите в DM.