Начинайте не с тарифа, а с решения, которое нужно получить
Название пакета мало говорит о результате. Один бизнес приходит без сайта, другой переносит действующий проект, третий теряет заявки между формой и менеджером. Одинаковый «тариф» для них будет либо неполным, либо перегруженным. Первый этап стоит определять через текущую проблему, ожидаемый результат и ограничения запуска.
- Сформулируйте исходную проблему Например: сайт не объясняет услугу, заявки не доходят, контент нельзя обновлять без разработчика или старый проект невозможно безопасно развивать.
- Зафиксируйте проверяемый результат Первый релиз должен заканчиваться работающим результатом: опубликованным сайтом, сохранением заявок, подключённой аналитикой и понятным способом обновлять контент.
- Отделите обязательное от следующей очереди Если функция не мешает принять первую заявку, проверить спрос или запустить основной процесс, её можно оценить отдельным этапом.
Четыре типовых сценария первого этапа
Новый сайт под одну услугу
Такой этап подходит, когда бизнесу нужно быстро получить управляемую точку входа для рекламы, рекомендаций и органического поиска.
Замена устаревшего сайта
Здесь первый этап определяется риском потери трафика и данных, а не количеством новых экранов.
Сайт с заявками и внутренним учётом
Этот формат уже ближе к веб-системе: оценивать его только по числу страниц неправильно.
Интеграция существующих систем
Интерфейс может быть небольшим, но основная стоимость находится в надёжности обмена и проверке ошибок.
Что должно остаться у бизнеса после первого релиза
- Рабочий production-адрес и понятный список того, что вошло в релиз.
- Доступы, резервная копия и проверенный способ отката.
- Проверенная форма или основной пользовательский сценарий без ложного успеха.
- Аналитика ключевого действия без передачи персональных данных.
- Инструкция по управлению контентом и перечень задач следующей очереди.
Как проверить смету до старта
- Есть граница этапа В смете описано, что можно принять и запустить, а не только перечислены дизайн, вёрстка и программирование.
- Отдельно названы зависимости Контент, интеграции, доступы, домен, почта и данные клиента не спрятаны в примечаниях.
- Понятен порядок проверки Для формы, аналитики, мобильной версии и публикации есть критерии приёмки.
- Следующая очередь не выдана за обязательную Будущие идеи оценены отдельно и не блокируют запуск основного сценария.
Пример: когда сайт перестаёт быть просто сайтом
В проекте 24V публичные страницы были связаны с PostgreSQL, NocoDB и сохранением заявок. Поэтому первый релиз включал не только интерфейс, но и данные, администрирование и проверку цепочки обращения. Такой состав нельзя корректно сравнивать с лендингом по числу экранов.