Я отказался от $40K-контракта, чтобы не переписывать Bitrix
Зимой мне позвонили с предложением, от которого не отказываются.
Интернет-магазин на Bitrix. 28 000 позиций в каталоге. Синхронизация с 1С, три региона доставки, восемь лет истории заказов. Всё это работало. Медленно, с техническим долгом слоями, но зарабатывало больше двух миллионов евро в год.
«Переписать всё. Bitrix тормозит рост бизнеса.» Три месяца. Порядка $40K.
Я попросил два дня.
Почему не «да» сразу
Я умею переписывать. Мне нравится чистый код. Когда предлагают проект с бюджетом и свободой в архитектурных решениях, профессиональный инстинкт говорит «берём».
Но было что-то, что меня остановило. Фраза «Bitrix тормозит рост» без единой цифры.
«Тормозит» — это не диагноз. Это симптом, который может означать двадцать разных проблем. Я попросил доступ к серверу и отчёт по выручке за год.
Что я нашёл за два дня
В логах было интересно.
Страница каталога делала 40 SQL-запросов на каждый визит. Не потому что Bitrix плохой, а потому что четыре года назад кто-то решил считать фасеты «живыми» — и с тех пор никто эту логику не пересматривал. Бизнес рос, ассортимент рос, запросы умножались. Решение не менялось.
LCP на странице каталога: 4,2 секунды. Причина не в стеке, а в конкретном коде на конкретной странице.
Параллельно: база данных 180 Гб. Из них 140 Гб — история сессий, которые никогда не чистились. Приложение тянуло балласт, который никто не замечал.
Bitrix здесь был ни при чём. Он делал то, что от него просили. Просили плохо.
Разговор, которого я боялся
Объяснить клиенту, что «проблема не в стеке» — неудобно. Особенно когда в голове уже есть красивая картинка нового сайта и новый стек как решение всех проблем.
Я сказал прямо: переписывание за $40K купит вам чистый код, но не решит ни одну из тех проблем, которые вы описываете как «Bitrix мешает». Медленная страница каталога — это не вопрос стека. Это конкретный запрос, который надо исправить. На любом стеке.
Три секунды тишины.
«Тогда что вы предлагаете?»
Что мы построили вместо
Мы разделили задачи: что действительно нужно менять, и что лучше не трогать.
Бэкенд остался на Bitrix. Заказы, ценообразование, синхронизация с 1С — это работающий код, который зарабатывает деньги. Трогать его без диагноза опасно.
Каталог переехал на Elasticsearch. Индексатор запускается раз в 15 минут, забирает данные из Bitrix пакетом и строит поисковый индекс. Те 40 SQL-запросов на страницу превратились в один запрос к Elasticsearch.
Поверх — Next.js-фронтенд. SSR для SEO-критичных страниц, клиентская фильтрация для остального. Старые Bitrix-шаблоны продолжили обслуживать корзину и личный кабинет — там всё работало нормально.
Шесть недель вместо шести месяцев.
Три месяца спустя
Цифры из первого месяца после запуска:
LCP на странице каталога: 1,4 секунды (было 4,2). Конверсия с мобильных: +23%. Индексация в Google не просела, URL-ы мы сохранили. Расходы на хостинг снизились, потому что Elasticsearch снял нагрузку с базы.
Клиент позвонил через три месяца не с претензией — с новым проектом.
Вот в чём разница между «правильным технически» и «правильным для бизнеса». Переписывание было бы правильным технически. Но не правильным для их денег и их времени.
Когда переписывание — действительно правильный ответ
Я не против rewrite. Иногда это единственный путь.
Например, когда технический долг охватил весь стек и новые фичи занимают в пять раз больше времени, чем должны. Или когда команда, которая понимала код, ушла. Иногда — когда бизнес-модель меняется настолько, что старая архитектура просто не поддерживает новые сценарии.
Но «Bitrix тормозит» без измерений — это не повод для рефакторинга против переписывания legacy. Это повод для диагностики.
Три вопроса, которые я задаю в начале любого разговора про переписывание:
Первый — что конкретно медленно, и есть ли цифры?
Второй — если это починить точечно, сколько времени займёт по сравнению с полным rewrite?
Третий — что произойдёт с бизнесом за те три-шесть месяцев, пока идёт переписывание?
Если на первый вопрос нет ответа с числами — нужна диагностика, а не смета на переписывание.
Настоящая стоимость rewrite — не строчка в контракте. Полгода без новых фич, пока конкурент выпускает обновления. Плюс технический долг нового стека, который начнёт накапливаться с первого коммита.
Иногда $40K контракт на переписывание — это $40K, потраченные не в ту сторону.