Самая низкая цена сайта часто означает не экономию, а работы, которые вынесли за смету. Я много раз видел сценарий: в КП стоит 390 тыс. ₽, а через месяц выясняется, что контент, аналитика, интеграция с CRM, тестирование форм и мобильная версия считались отдельно. На старте это выглядит как выгодная сделка. На практике - как проект, который дорожает по ходу.
Ошибка обычно случается не в момент поиска подрядчика, а в момент согласия на удобное предложение без лишних вопросов. Ниже - проверки, которые помогают отсечь слабую команду еще до договора.
Одинаковый экран не означает одинаковый проект
Один и тот же сайт на скриншоте может стоить 450 тыс. ₽, 980 тыс. ₽ или 1,6 млн ₽. Услуга называется одинаково, но внутри это три разных проекта. В одном случае это шаблон на WordPress, в другом - Laravel 11 с каталогом, оплатой и ролями, в третьем добавятся SEO-структура, staging, интеграция с 1С или ERP, GA4, Яндекс Метрика и поддержка после релиза.
Мы разбирали смету интернет-магазина для оптовой компании. Клиент смотрел только на итоговую цифру и не понимал, почему разница почти в три раза. Когда открыли состав работ, оказалось, что в дешевом КП нет миграции 12 000 товаров, фильтров, обмена с 1С и тестирования оплаты. После этого сравнивать просто "стоимость сайта" уже не имело смысла.
Частая ошибка:
- смотреть только на финальную сумму;
- считать, что "адаптив" и "интеграции" входят по умолчанию;
- обсуждать дизайн раньше структуры и сценариев;
- принимать фразу "допилим после запуска" как нормальный план.
Как правильнее:
- просить список того, что не входит в цену;
- фиксировать допущения и ограничения письменно;
- сравнивать КП построчно, а не по одной цифре.
Если подрядчик не спрашивает про бизнес, он просто собирает страницы
Когда на первом созвоне разговор быстро уходит в CMS, стек и предоплату, это плохой сигнал. Сильная команда сначала выясняет, зачем компании сайт: получать лиды, продавать, разгружать менеджеров, запускать личный кабинет, проверять новую нишу. От этого зависят структура, интеграции и состав страниц.
У нас был проект для B2B-компании в услугах. Клиент просил обычный сайт на 10 страниц. После интервью стало ясно, что ему нужны 4 посадочные страницы, калькулятор и связка с amoCRM, а половина стандартных разделов только мешает заявке.
После запуска через 8 недель:
- 4 посадочные страницы вместо десяти;
- автоматическая передача заявок в amoCRM;
- стоимость заявки ниже на 27% через 2 месяца.
Мы сами однажды взялись за проект слишком быстро и переделывали логику на 5 неделе, когда уже в работе выяснились роли пользователей и правила согласования заявок. С тех пор я больше доверяю качеству вопросов на первой встрече, чем красивому портфолио.
Договор показывает качество проекта еще до старта
Самые дорогие проблемы начинаются там, где не определено, что именно значит "сайт готов". Форма может отправлять письмо, но не передавать лид в CRM. Каталог может открываться, но на мобильных работать так медленно, что реклама сливает бюджет. Дизайн может быть утвержден, хотя на части iPhone верстка уже едет.
В договоре я бы смотрел не только оплату и срок. Нужны этапы, критерии приемки, порядок доработок, список доступов, права на код и дизайн, ответственность за контент и внешние сервисы. Если этого нет, спор просто переедет из продажи в приемку.
Если доступы обсуждают "после запуска", зависимость от исполнителя уже заложена в проект.
Один клиент пришел к нам после релиза у другого подрядчика. Сайт работал, но у компании не было доступа к Git, Figma, панели хостинга и аналитике. Перенос занял 2 месяца и добавил к бюджету еще 320 тыс. ₽. В таких случаях бизнес покупает не сайт, а зависимость от исполнителя.
Запуск - не финиш, а первая проверка архитектуры
После релиза обычно и становится видно, что именно вы купили. Если проект собран на скорую руку, любая новая задача начинает ломать старые решения. Английская версия, кабинет дилера, новый способ оплаты, обмен с 1С - и внезапно оказывается, что дорого менять почти все.
Для бизнеса есть простой набор маркеров зрелости: Git и версионирование, staging/dev-среда, логирование ошибок, документация по деплою и доступам, контроль скорости по LCP, INP и CLS. Это не детали для пресейла, а вещи, которые потом экономят недели и сотни тысяч рублей.
Недавно мы подключались к каталогу на 5 000 SKU, который сначала делали "побыстрее". Через три месяца заказчику понадобились английская версия, кабинет дилера и обмен с 1С. На старой базе это стоило почти как новый проект. Мы пересобрали бэкенд на Node.js 20 + NestJS, данные вынесли в PostgreSQL 16, и дальше задачи пошли короткими итерациями по 1-2 недели.
Восемь вопросов, которые стоит задать до предоплаты
Полезны не обещания, а письменные ответы. Я обычно советую отправлять подрядчикам один и тот же список и смотреть не только на содержание, но и на ясность формулировок.
1. Как вы считаете цену проекта?
2. Что входит в работу, а что пойдет как допработы?
3. Кто будет в команде и кто принимает решения?
4. Какие похожие проекты вы делали и что там сломалось по ходу?
5. Как собираете требования - интервью, user flow, прототип, Figma?
6. Как устроены тестирование, приемка и исправления?
7. Кому принадлежат код, дизайн, домен, доступы и инфраструктура?
8. Как будет устроена поддержка после запуска?
Если хотя бы на 3 из 8 вопросов вы получаете расплывчатый ответ или обещание "обсудить после подписания", дальше идти не стоит. Соберите все КП в одну таблицу, отправьте этот список двум-трем подрядчикам и попросите ответить письменно. По моему опыту, слабая команда часто отсеивается еще до договора.
