Как начать сложный сайт без большого бюджета: discovery и первый work slice

Когда бизнес приходит за нестандартным сайтом, честная оценка не начинается с фиксированной цены. Сначала нужно понять, что именно считается рабочим результатом: роли пользователей, данные, интеграции, сценарии, ограничения по срокам и критерии приемки.

Почему нельзя оценивать сложный сайт одним числом

Две задачи с одинаковым названием могут отличаться в разы. Интернет-магазин с одним каталогом и сайт с B2B-ролями, 1С-обменом, личными кабинетами и несколькими складами требуют разного scope, тестов и запуска. Если это смешать в одну строку сметы, риск просто переезжает в середину проекта.

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

Мы начинаем с короткого discovery: собираем предварительные требования, отделяем базовое от optional и client-specific, отмечаем риски по данным и интеграциям. После этого можно выбрать маленький work slice: аудит, прототип обмена, один экран с API или ограниченный production-safe участок.

• Base scope: без чего первый результат не работает.
• Optional: улучшения, которые не должны блокировать старт.
• Risk map: где возможны задержки: данные, роли, права, внешние API, SEO, нагрузка.
• Acceptance criteria: что должно быть проверено на staging или в production-safe окружении.

Что это дает клиенту

Клиент видит скорость команды, качество коммуникации, Git Flow, staging-проверки и подход к документации до большого бюджета. Команда видит реальные ограничения проекта, а не угадывает их по брифу. Это особенно важно для replatform, интеграций и нестандартных сайтов, где цена зависит от данных, workflows и внешних систем.

Если первый slice подтверждает гипотезу, следующий шаг уже можно оценивать по этапам или вести по T&M. Если нет, остановка обходится дешевле, чем большой проект с неправильным scope.

Посмотреть формат кастомной веб-разработки WGP или начать с пилота.