← Назад в блог

Rewrite - это не scope. Это симптом, который надо разобрать

Фраза «нам нужен rewrite» почти никогда не описывает работу.

Она описывает усталость.

Сайт медленный. Релизы тяжёлые. Подрядчик пропал. В Bitrix страшно трогать шаблоны. Маркетинг ждёт две недели простую посадочную страницу. CTO слышит от команды: «это проще переписать».

Иногда команда права. Иногда нет.

Проблема в том, что rewrite звучит как понятный план, хотя на старте это только гипотеза. Если сразу превратить её в смету, в проект поедут все скрытые риски: SEO, каталог, роли, checkout, 1C-обмен, CRM, контентная модель, миграция данных и ответственность за rollback.

Я бы не начинал такой разговор с бюджета. Я бы начинал с карты риска.

Что именно болит

Первый вопрос простой: что станет лучше, если завтра появится новый frontend?

Если ответ «сайт станет быстрее», надо проверить, где тормозит сейчас: SQL, шаблоны, API, изображения, фильтры, CDN, внешний сервис, персональные цены или поиск.

Если ответ «команда начнёт быстрее выпускать изменения», надо смотреть deploy flow, зависимости между backend и frontend, права контент-команды, очередь задач и то, где изменения ломают production.

Если ответ «мы уйдём от старого подрядчика», это уже не только архитектурная задача. Это transfer of ownership: документация, доступы, Git history, окружения, knowledge base и договорённость, кто принимает решения.

Один и тот же слово rewrite может означать три разных проекта.

Что нельзя трогать в первой итерации

В старых e-commerce проектах часть системы выглядит некрасиво, но зарабатывает деньги.

Например:

  • checkout с кучей исторических правил скидок;
  • личный кабинет с нестандартными ролями;
  • 1C-обмен, который работает только потому, что его никто не трогал;
  • SEO-страницы, которые собирают органику по старым URL;
  • CRM-интеграция с ручными исключениями;
  • выгрузка остатков, где бизнес-логика живёт не в коде, а в привычках команды.

Это не значит, что их нельзя модернизировать. Значит, их нельзя случайно включать в первый scope только потому, что слово rewrite звучит крупно.

Иногда лучший первый шаг - вынести каталог или поиск. Иногда - сделать новый слой для SEO-страниц. Иногда - оставить checkout в Bitrix и дать Next.js только read-only витрину.

Headless хорош не тем, что «всё новое». Он хорош тем, что можно вынести часть системы без пожара в остальной.

Почему fixed price здесь опасен

Для продуктового формата fixed price нормален: повторяемый scope, понятные ограничения, известная команда.

Для кастомного rewrite fixed price до discovery часто означает, что риск просто спрятали в формулировках.

Потом он вернётся:

  • «мы не знали, что цены считаются через кастомный модуль»;
  • «мы не закладывали отдельные правила для B2B-клиентов»;
  • «мы думали, что фильтры можно перенести один к одному»;
  • «мы не видели, что половина SEO-трафика сидит на индексируемых параметрах»;
  • «нам не сказали, что менеджеры руками правят остатки перед акцией».

Честная оценка начинается после компактного discovery: предварительные требования, базовый scope, optional/client-specific функциональность, интеграции, данные, роли, workflow и acceptance criteria.

До этого можно оценить только первый work slice. Не весь переписанный мир.

Какой slice я бы выбирал

Хороший pilot должен быть маленьким, но не игрушечным.

Мне нравятся участки, где виден бизнес-эффект и технический риск:

  1. Одна каталоговая категория с тяжёлыми фильтрами.
  2. Поиск на реальных запросах и zero-results логах.
  3. SEO-посадочная страница поверх существующих данных.
  4. Read-only личный кабинет без оплаты и изменения заказов.
  5. API-контракт для товара, цены, наличия и картинок.

У pilot должны быть критерии. URL открывается. Данные совпадают. Метаданные не потеряны. Скорость лучше. Rollback понятен. Команда увидела Git Flow, staging и production checks.

Если pilot не проходит эти критерии, это не провал. Это дешёвое обнаружение риска.

Что получает owner или CTO

После нормального pre-rewrite audit должно быть понятно:

  • какая боль реальная, а какая звучит громче остальных;
  • что можно вынести первым без риска для продаж;
  • что оставить в старом контуре до отдельного решения;
  • какие данные и интеграции управляют стоимостью;
  • какой pilot покажет результат без большого обещания;
  • где нужен developer judgment, а где достаточно обычной задачи в backlog.

Это скучнее, чем презентация «перепишем на современный стек».

Зато это разговор, который можно защищать перед бизнесом. Не потому что архитектура красивая. Потому что следующий шаг ограничен, измерим и не требует верить на слово.

Связанное чтение: пять вопросов перед headless-предложением, перед rewrite Bitrix я считаю риск, а не бюджет, что остаётся в Bitrix при headless-переходе.