Доработка старого сайта или разработка с нуля — вопрос не про моду, а про деньги и сроки. В MiWix мы годами сталкиваемся с этим выбором. И чаще всего решение упирается не в амбиции заказчика, а в состояние самого сайта. Ниже — без воды, по делу.
Состояние кода — первый фильтр. Если в проекте накопились костыли, нет документации, а правки ломают соседние функции — доработки съедают бюджет быстрее, чем кажется. Мы видели сайты, где одна кнопка тянет за собой пять багов. В таких случаях дешевле и спокойнее начать заново. Но если код чистый, модули отделены, есть тесты — доработка оправдана. Тут важно не гадать, а провести аудит: посчитать количество технических долгов, оценить покрытие тестами, проверить зависимости. Простой маркер: если на мелкую задачу уходит в 3–5 раз больше времени, чем должно — код просит замены.
Архитектура решает, насколько гибко сайт будет расти. Устаревшая архитектура — это когда любая новая фича требует переписывать половину логики. Например, магазин, где корзина и каталог живут в разных системах, а синхронизация сделана скриптом на коленке. Интеграции в таких проектах держатся на ручных выгрузках и Excel (программа для таблиц). Мы встречали проекты, где подключение CRM (управление клиентами) занимало три месяца только из-за того, что API (интерфейс взаимодействия) не было вообще. Если архитектура не позволяет масштабироваться без переписывания ядра — лучше делать с нуля. Если модули можно менять по отдельности и система не разваливается при добавлении нового — дорабатывайте.
Интеграции — отдельная история. Если сайт должен работать с CRM (управление клиентами), 1С, маркетплейсами, платёжными шлюзами, то совместимость решает многое. Старый сайт может не поддерживать современные протоколы или требовать сложных прослоек. В одном кейсе клиент хотел подключить онлайн-бронирование к сайту на самописном движке 2012 года. Оказалось, что проще поднять новый модуль на современной стеке, чем пытаться подружить старый код с API (интерфейс взаимодействия). Если интеграции требуют костылей и постоянных правок — это сигнал к перезапуску. Если API (интерфейс взаимодействия) стабильны и есть готовые коннекторы — доработка уместна.
Сроки — самый жёсткий критерий. Доработка обычно быстрее, если не вскрываются скрытые проблемы. Но если в процессе всплывает, что база данных в плохом состоянии, а верстка не адаптируется под мобильные — сроки улетают. Мы фиксировали случаи, когда доработка на 2 недели растягивалась на 2 месяца. Новый проект можно планировать точнее: есть этапы, контрольные точки, понятные риски. Если сроки жёсткие и нельзя рисковать — новый сайт предсказуемее. Если дедлайн не горит и правки точечные — дорабатывайте.
Бюджет — главный ограничитель. Новый сайт стоит дороже на старте, но может быть дешевле в долгосрочной перспективе. Доработка дешевле сегодня, но дороже завтра, если придётся постоянно латать дыры. Простой расчёт: считаем стоимость часа разработки, умножаем на ожидаемое количество часов доработки и сравниваем с ценой нового проекта. Добавляем риски: умножаем оценку доработки на 1.5–2, потому что в старом коде всегда есть сюрпризы. Если результат доработки выходит дороже нового сайта — смысла нет.
Формула принятия решения выглядит так:
- Считаем стоимость доработки: часы × ставка × 1.5 (запас на риски).
- Сравниваем с ценой нового сайта.
- Проверяем архитектуру: можно ли добавить нужные функции без переписывания ядра.
- Смотрим интеграции: сколько времени уйдёт на подключение новых систем.
- Оцениваем сроки: готовы ли вы к возможным задержкам.
Если по пунктам 3 и 4 ответ «нет» или «очень сложно», а по пункту 2 доработка выходит дороже нового проекта — делайте с нуля. Если всё ок и доработки укладываются в бюджет — продолжайте развивать старый сайт.
Пример из практики MiWix: клиент пришёл с интернет-магазином на старом фреймворке. Хотели добавить личный кабинет и интеграцию с маркетплейсом. Аудит показал, что ядро не поддерживает сессии, а база данных не нормализована. Доработка оценивалась в 600 часов, новый сайт — в 400. Мы предложили новый проект. Клиент сначала сопротивлялся, но после демонстрации рисков согласился. В итоге запустили быстрее и дешевле, чем планировали на доработке.
Ещё один случай: лендинг на WordPress (платформа для управления сайтами) с чистым кодом и понятной структурой. Клиент хотел добавить форму с расчётом стоимости и интеграцию с CRM (управление клиентами). Доработка заняла 40 часов. Новый сайт тут был бы избыточен — функционал точечный, архитектура позволяет.
Вывод простой: не тяните с аудитом. Он стоит недорого, но экономит десятки часов и сотни тысяч рублей. В MiWix мы сначала смотрим код и архитектуру, потом считаем деньги, и только потом решаем — дорабатывать или строить заново.
Обновлено
