Не начинайте rewrite сайта без короткого discovery

Большой rewrite почти всегда начинается одинаково: текущий сайт тормозит, маркетинг не может быстро запускать страницы, каталог и поиск ведут себя непредсказуемо, а команда уже устала чинить симптомы. В этот момент легко попросить подрядчика назвать срок и бюджет «за новый сайт». Но честная оценка до discovery обычно будет либо слишком общей, либо опасно уверенной.

Для e-commerce, Bitrix-backed систем, B2B-порталов и сайтов с интеграциями правильнее начинать не с обещания фиксированной цены, а с короткого технического и продуктового discovery. Его задача — быстро понять, что именно мешает росту, где лежит риск простоя, какие части можно вынести поэтапно и какой первый slice даст измеримый результат.

Что собрать до оценки

• Бизнес-контекст: что сейчас теряется — скорость релизов, SEO, конверсия, стабильность, управляемость каталога или стоимость поддержки.
• Технический контур: CMS, API, 1C/ERP/CRM, поиск, роли пользователей, платежи, доставка, аналитика, staging/production процесс.
• Контент и данные: URL-структура, каталог, фильтры, canonical/redirect rules, sitemap, локализации, критичные шаблоны.
• Acceptance criteria: какие проверки покажут, что первый этап сработал: скорость, индексируемость, стабильность, управляемость релизов, качество поиска.

Как не превратить discovery в 100-страничный документ

Мы обычно разделяем требования на три слоя: base functionality, optional functionality и client-specific logic. Так клиент видит, что действительно нужно для первого результата, а что можно отложить до следующего этапа. Это снижает риск «вечной стройки» и делает разговор о бюджете предметным.

Например, базовый слой может включать безопасное подключение Next.js-фронта к существующему backend/API, сохранение SEO-структуры и контрольный набор страниц. Optional — расширенную админку, дополнительные роли, новые интеграции или сложные сценарии персонализации. Client-specific — правила, которые есть только в вашем бизнесе: нестандартные workflow, права доступа, ассортиментные исключения, внутренние отчеты.

Почему маленький pilot лучше большого обещания

Если система уже приносит деньги, ее нельзя ломать ради красивого redesign. Небольшой pilot или test slice позволяет проверить workflow команды, качество кода, staging-процесс, скорость коммуникации и реальную сложность интеграций. Для headless/replatform задач это часто честнее, чем сразу продавать «полный переезд».

Хороший первый slice может быть таким: вынести одну категорию каталога, один лендинг, один поисковый сценарий или одну связку CMS/API/frontend. После этого появляется фактура: что было просто, где риск, какие данные грязные, насколько команда готова к staged rollout.

Как WGP подходит к таким проектам

WebGoodPeople работает быстро за счет опытной команды, AI-assisted development, готовых компонентов и прозрачного Git Flow. Но скорость не заменяет review, staging, production checks и аккуратную работу с SEO. Исходный код, знания по проекту и документация должны оставаться открытыми для клиента, чтобы сайт не превращался в черный ящик.

Если вы смотрите на rewrite, headless-переход или сложную интеграцию, начните с компактного discovery: покажите текущую боль, доступные данные и желаемый первый результат. Дальше можно собрать короткий scope и выбрать безопасный pilot вместо большого риска.

Обсудить discovery или pilot с WGP · Посмотреть процесс работы · Услуги WGP