Что прислать перед оценкой custom-сайта или replatform

Если нужно быстро получить адекватную оценку кастомного сайта, replatform или интеграции, начните не с “сколько стоит сайт?”, а с короткого brief. Чем яснее входные данные, тем меньше запасов, догадок и спорного scope в коммерческом предложении.

Для WGP это особенно важно в проектах с Bitrix, Laravel, Next.js, Elasticsearch, каталогами, личными кабинетами и внешними API. Там цена определяется не количеством экранов, а связками данных, ролями, интеграциями, рисками релиза и критериями приемки.

Что прислать перед оценкой

• Цель проекта. Что должно измениться для бизнеса: скорость сайта, лиды, SEO, запуск новых разделов, снижение ручной работы, подготовка к росту.
• Текущий стек. CMS, backend, frontend, хостинг, основные интеграции, кто поддерживает систему сейчас.
• Критичные сценарии. Каталог, поиск, checkout, заявки, личный кабинет, роли, импорт/экспорт, CRM/ERP/1C, платежи, уведомления.
• Что нельзя сломать. SEO URL, фильтры, заказы, остатки, аналитика, пик продаж, внутренние workflow команды.
• Данные и доступы. Где живет каталог, есть ли API, какие форматы импорта, кто владеет контентом и правилами.
• Ограничения по срокам. Дедлайны, сезонность, рекламные кампании, окна релиза, требования к staging.
• Acceptance criteria. Как будет понятно, что работа готова: сценарии, метрики, чек-листы, production checks.
• Желаемый первый шаг. Audit, pilot, test slice или сразу подготовка backlog для большого проекта.

Как мы используем brief

Сначала отделяем базовый scope от optional/client-specific частей. Затем отмечаем зоны неопределенности: интеграции, данные, роли, миграцию, нестандартный поиск, требования к downtime. После этого предлагаем самый короткий безопасный шаг: audit, pilot или небольшой work slice.

Fixed price мы обещаем только там, где границы продукта уже понятны: например, в упакованных Frontbox-форматах. Для custom-разработки честнее показать зависимость оценки от scope, интеграций, данных, workflows и acceptance criteria.

Что получает клиент

Не “магическую цену за сайт”, а понятный следующий шаг: что проверяем, что делаем первым, где риски, что можно отложить, как выглядит staging/production acceptance и как команда будет видеть прогресс через Git Flow, проверки и документацию.

Отправить brief в WGP или сначала посмотреть наш процесс работы.