В прошлом году к нам пришел владелец небольшого отеля. Он был уверен, что сайт не продает из-за старого дизайна: мобильный трафик уже был выше 70%, а броней почти не было. Мы посмотрели путь клиента в Метрике и увидели другую картину: на телефоне человек проходил 6 экранов до первого понятного шага, а условия отмены и тарифы терялись по дороге.
Такая история повторяется часто. Бизнес обсуждает редизайн ради редизайна, хотя проблема обычно в другом: сайт заказали не под тот сценарий, который реально нужен клиенту. Если понять это до старта, можно сэкономить десятки процентов бюджета и не тащить в релиз лишние функции.
Сайт "просто нужен" - это не задача
Один и тот же запрос может означать четыре разных продукта. Для сервисной компании сайт должен привести к заявке. Для мебельного бизнеса - к расчету. Для отеля - к выбору дат и броне. Для магазина типовых товаров - к оплате.
Рабочая логика простая:
- заявка или звонок - лендинг или сайт услуг
- много позиций без онлайн-оплаты - каталог
- фиксированный товар с доставкой - интернет-магазин
- даты, слоты, номера, тарифы - сайт с бронированием
У нас был проект в B2B-услугах, где клиент хотел корпоративный сайт на 40+ страниц. После интервью с отделом продаж мы сократили первую версию до 9 страниц, оставили только нужные сценарии, добавили форму отправки ТЗ и связку с amoCRM. Запустились за 7 недель и в первый месяц получили 31 целевой лид.
Если уже есть соцсети и маркетплейсы, сайт правда нужен?
Нужен, когда важны свои данные, своя аналитика и прямой трафик без чужих правил. По сути, это не всегда большой проект - часто хватает MVP на 5-10 страниц.
Бюджет растет из-за логики, а не из-за картинок
Я не раз видел сметы, которые отличались почти в 3 раза при похожем визуале. Разница почти всегда была в сценариях: роли пользователей, импорт каталога, синхронизация с CRM, платежи, 1С, склад, мультиязычность, модуль бронирования, админка для контента.
Для малого бизнеса мы обычно считаем запуск в трех слоях: стартовая версия, рабочая версия, версия с автоматизацией. На деле это спасает от дорогой привычки строить "идеальный сайт" в первом релизе.
| Формат | Что получает бизнес | Срок | Бюджет |
|---|---|---|---|
| Лендинг | заявки и проверку спроса | 3-5 недель | 180-350 тыс. ₽ |
| Сайт услуг | поток лидов | 6-10 недель | 350-900 тыс. ₽ |
| Каталог | подбор и обращения | 8-12 недель | 700 тыс. - 1,6 млн ₽ |
| Магазин | онлайн-продажи | 10-16 недель | 1,2-2,5 млн ₽ |
| Бронирование | выбор дат и оплату | 8-14 недель | 900 тыс. - 2,2 млн ₽ |
Сразу ставьте GA4, Яндекс Метрику и базовую проверку скорости через Lighthouse. Сайт без аналитики - это расход, который нечем измерить.
Интернет-магазин нужен далеко не всем
Самая частая ошибка - заказывать e-commerce там, где клиент не готов покупать через корзину. Для мебели, оборудования, части B2B, медицины, гостиниц и сложных услуг человеку чаще нужен расчет, подбор, запись или бронь.
С мебельной компанией мы пошли именно так: вместо полноценного магазина сделали каталог хитов, квиз на подбор и формы расчета. Первая версия стоила почти вдвое дешевле, а конверсия в обращение оказалась выше, чем в прогнозе по корзине.
С отелем было похоже. Мы оставили стек Laravel 11 + PostgreSQL 16, но полностью сократили мобильный путь: тарифы, наличие и условия отмены вынесли на первый экран карточки номера. За 5 недель после запуска конверсия в бронь выросла с 0,8% до 2,3%.
CTO логистической платформы как-то точно сформулировал это на созвоне: "Самый частый перерасход бюджета возникает из-за попытки автоматизировать все процессы в первом релизе".
Хороший бриф экономит недели, плохой - раздувает проект
Нормальный бриф - это не "хотим современно, как у конкурента". Нужны цель сайта, целевое действие, типы страниц, обязательные интеграции, сроки, диапазон бюджета и человек, который отвечает за контент.
Мы сами когда-то заходили в проекты по слишком общему описанию. Один раз это не сработало: локальный бренд попросил сразу каталог, личный кабинет, промокоды, рекомендации, сложную доставку и интеграцию со складом. Контент не подготовили, трафика почти не было, проект затянулся, а бизнес получил дорогую систему без продаж. По сути, им нужен был каталог с лидогенерацией и аналитикой, а тяжелый магазин стоило делать позже.
Цель сайта:
Целевое действие:
Типы страниц:
Интеграции:
Кто готовит контент:
Срок запуска:
Диапазон бюджета:
KPI после релиза:
Что спросить у подрядчика на первой встрече?
Пусть покажет, что войдет в MVP, что пойдет во второй этап и по каким цифрам через 30-90 дней вы поймете, что сайт работает. Если разговор сразу уходит в цвета кнопок и "сделаем любой сайт за 2 недели", я бы на этом месте тормозил.
Смотреть надо не только на смету, но и на права
Если проект делают на WordPress или Laravel 11, вы должны с самого начала понимать, где лежит код, кто владеет доменом, хостингом и доступами, как обновляется контент и сколько стоит развитие после релиза. Вопросы скучные, но именно на них потом ломается половина "дешевых" запусков.
Мы предпочитаем передавать клиенту все доступы, репозиторий и понятную схему поддержки. Иначе сайт превращается в закрытую коробку, которая вроде работает, но любое изменение стоит непропорционально дорого.
Я бы начал с одного вопроса: какое одно действие человек должен сделать на сайте в первые 30 секунд. Если ответа нет, смету можно не открывать. Самая дорогая функция на сайте - та, которой никто потом не пользуется.
