Scope до бюджета: как оценивать кастомную разработку без фикса вслепую

Когда сайт уже влияет на продажи, опасно начинать кастомную разработку с вопроса «сколько будет стоить весь проект?». Без контекста этот вопрос толкает подрядчика либо в красивую, но пустую вилку, либо в фиксированную цену с большим скрытым запасом.

Более здоровая рамка: сначала собрать компактный scope, отделить базовую функциональность от optional-блоков и выбрать первый проверяемый work slice. Так owner, CTO и маркетинг видят, какие решения действительно двигают бюджет.

Что нужно понять до оценки

• Критичные сценарии. Каталог, поиск, фильтры, корзина, checkout, личный кабинет, формы заявок и страницы, которые дают органику или лиды.
• Интеграции. 1С, CRM, оплаты, доставки, маркетплейсы, аналитика, email/SMS, внешние API и ограничения по доступам.
• Данные и роли. Кто управляет контентом, кто принимает заказы, какие права нужны, какие данные мигрируют и где сейчас источник истины.
• Acceptance criteria. Какие URL, метрики, формы, события аналитики, SEO-условия и performance-показатели считаются готовым результатом.

Почему fixed price до discovery обычно вреден

Для продуктовых форматов с фиксированным scope цена может быть понятной заранее. Для кастомной разработки, replatform, интеграций и нестандартных сайтов стоимость зависит от данных, ролей, workflows, API, SEO-рисков и критериев приёмки.

Если зафиксировать цену до этого разговора, команда начинает защищать смету, а не результат. Клиент получает не прозрачность, а спор о том, «входит ли это в договор».

Как выглядит безопасный следующий шаг

Мы предпочитаем начинать с малого проверяемого этапа: аудит, pilot, integration spike или release-support slice. У такого этапа есть ограниченный scope, демо-точка и понятные критерии: что должно открыться в браузере, какие сценарии проходят, какие метрики смотрим и какие риски закрыты.

Для e-commerce на Bitrix это часто выглядит так: сначала 48-часовой разбор, потом пилот на одной категории или отдельный work slice по поиску, каталогу, checkout или аналитике. Полный бюджет появляется после того, как базовый и optional scope перестали смешиваться.

Что отправить нам для первого разбора

• Ссылку на текущий сайт и 3-5 главных бизнес-задач.
• Список интеграций и сервисов, которые нельзя сломать при запуске.
• Примеры страниц или сценариев, где сейчас теряется скорость, SEO, конверсия или управляемость.
• Ограничения по срокам, команде, хостингу, доступам и юридическим требованиям.

После этого можно говорить предметно: какой scope базовый, что optional, где нужен spike, где достаточно поддержки релизного процесса, а где лучше не начинать большой проект вообще.

Пришлите задачу — вернёмся с короткой картой scope и следующим проверяемым шагом.