Недавно к нам пришел клиент из B2B-дистрибуции с понятным запросом: нужен сайт за 2 месяца, там ничего сложного. Разложили задачу на структуру, тексты, каталог, CRM, legal, QA и запуск - получили уже 14 недель, и это еще без кабинета. Короче, срок сайта почти никогда не равен сроку разработки.
Если вы сейчас планируете запуск, полезнее считать не страницы, а нерешенные вопросы. Я бы смотрел так: лендинг - 2-5 недель, корпоративный сайт - 8-16 недель, интернет-магазин - 3-6 месяцев, кабинет или платформа - от 4 до 9 месяцев.
Срок уезжает там, где бизнес считает «это потом решим»
Самая частая ошибка - считать только код. Хотя проект начинается раньше: discovery, карта сайта, прототипы, дизайн, тексты, QA, UAT, запуск. Если этого нет в плане, срок уже занижен.
У нас был корпоративный сайт с каталогом на Laravel 11 и PostgreSQL 16. Оценка была 10-12 недель, по факту вышло 18 недель. Из них 2 недели ждали структуру от маркетинга, 1,5 недели ушло на переписывание текстов, еще 2 недели - на CRM-интеграцию, 3 дня заняли cookie banner и правки юристов. Половина сроков там жила вне кода.
Мини-диалог был почти учебный:
- Когда начнете верстку?
- Как только утвердим карту сайта.
- А это обязательно? Давайте сначала делать.
- Обычно после этой фразы сроки и уезжают.
Ранний старт без решений выглядит бодро только в начале. Потом те же вопросы возвращаются уже в дизайне, шаблонах, формах и админке, и каждый ответ стоит дороже.
Есть этапы, которые не ужимаются без переделок
Для сайта на 20-30 страниц рабочий цикл у нас обычно такой: discovery - 1-2 недели, прототипы - 1-2 недели, дизайн - 2-4 недели, разработка - 3-6 недель, контент, QA и релиз - 1-3 недели. В сумме и выходит честный коридор 8-16 недель.
Один раз мы сами решили ускориться и начали дизайн до фиксации структуры. Выиграли 4 дня, потеряли почти 2 недели на переделке шаблонов и мобильных состояний. С тех пор я такие «ускорения» не люблю.
| Что можно вести параллельно | Что лучше не трогать раньше времени |
|---|---|
| подготовку контента и прототипы | финальный UI без структуры |
| API и UI-kit | SEO-сборку без URL-карты |
| staging и часть QA | релиз без UAT |
Discovery -> Scope freeze -> Design -> Dev -> QA -> UAT -> Release
Фраза «пока поставьте заглушки» почти всегда означает двойную работу через две недели. На практике вопросы не исчезают, они просто переезжают в более дорогую фазу.
Цена сайта растет не от страниц, а от количества решений
Когда бизнес сравнивает сметы «по страницам», это почти всегда уводит в сторону. Цена сайта зависит от интеграций, ролей, состояний интерфейса, данных и того, как всем этим управлять после запуска.
Недавно было два запроса: нужен интернет-магазин. Первый - 200 SKU, онлайн-оплата, доставка, без ERP. Второй - 20 000 SKU, несколько складов, дилерские цены, обмен с 1С, личный кабинет. Разница по бюджету между ними была почти в 4 раза, хотя снаружи оба назывались одинаково.
Низкая цена часто означает, что из сметы выпали неприятные куски: мобильные состояния, SEO-база, миграция контента, QA, админка, импорт каталога. Самый дешевый способ купить сайт - заранее убрать неопределенность: зафиксировать MVP, список интеграций и владельца контента.
Главный тормоз проекта - материалы и согласования
Самый болезненный участок обычно на стороне бизнеса. Тексты, фото, карточки, FAQ, политика обработки данных, редиректы, метаданные - это почти всегда недооценено. Если решения принимают в общем чате сразу 5 человек, проект начинает ходить по кругу.
У нас был каталог для промышленной компании на WordPress с кастомными блоками и выгрузкой из CSV. Хотели стартовать быстро, пошли без финальной структуры и без человека, который отвечает за контент. В итоге 600 карточек грузили вручную вместо импорта, фото приехали от 5 поставщиков в разном размере, а тексты согласовывали через 4 менеджеров. Задержка вышла около 40%.
Вот короткий чеклист, после которого срок обычно становится реалистичнее:
- есть утвержденная структура и список страниц;
- зафиксирован MVP первого релиза;
- понятно, кто со стороны клиента принимает решение за день, а не за неделю;
- интеграции описаны нормально, а не фразой «там просто API»;
- контент готовится к конкретной дате, а не «по ходу».
Нормальный запуск - это релизы, а не вечная стройка
Я бы сделал так: первый релиз собираем вокруг продаж и заявок. Публичные страницы, формы, аналитика, базовая CRM-интеграция, админка для контента. Все, что не влияет на старт прямо сейчас, уходит во второй этап.
На проекте сервиса бронирования мы выпустили публичную часть, форму заявки и базовый кабинет за 11 недель. Онлайн-оплату, отзывы и бонусную механику вынесли еще на 6 недель. Клиент начал получать заявки раньше, а команда не тонула в вечном «раз уж делаем, давайте еще вот это».
После релиза я почти всегда прошу сразу согласовать план на 30-60 дней: аналитика, SEO, проверка конверсии, узкие места по формам и каталогу. Иначе сайт формально запущен, но бизнес опять живет в режиме «сейчас еще чуть-чуть доделаем».
Когда тот клиент из начала статьи просил сайт за 2 месяца, ему на самом деле нужен был не быстрый подрядчик, а список решений, которые нельзя откладывать. Если хотите проверить свой срок на реальность, спросите не «когда будет готово», а «что с моей стороны должно быть готово к пятнице». Вот там и лежит настоящий дедлайн.
