Не количество страниц: что на самом деле формирует стоимость сайта или портала

Разница между сайтом за 500 тыс. рублей и порталом за 8 млн часто находится не в дизайне и не в количестве страниц. Она появляется там, где начинаются роли, данные, интеграции, миграция и требования к эксплуатации.

Алексей Постригайло, старший партнер ИТ-интегратора «Энсайн», разбирает, почему оценки подрядчиков на один проект могут расходиться в разы и как отличить простую веб-разработку от полноценной информационной системы.

Заказчик отправляет одно описание нескольким подрядчикам и получает три сметы: 500 тыс., 3 млн и 8 млн рублей. Внешне кажется, что кто-то сильно ошибся. Иногда так и есть. Один подрядчик может демпинговать, другой — закладывать завышенный резерв.

Но чаще проблема в другом. Команды оценивают не один и тот же продукт.

Одна видит корпоративный сайт на готовой CMS. Вторая учитывает индивидуальный интерфейс, интеграции и административную часть. Третья воспринимает проект как портал с ролевой моделью, бизнес-процессами, данными и требованиями к отказоустойчивости.

Во всех трех случаях в запросе может стоять слово «сайт». По трудоемкости это разные классы систем.

Какие бюджеты считать реалистичными

Для предварительного планирования можно использовать такие ориентиры.

Лендинг или небольшой промосайт обычно стоит 150-500 тыс. рублей. Корпоративный сайт на готовой платформе — 500 тыс. - 1,5 млн. Индивидуальный корпоративный сайт — 1,5-3 млн. Если появляется каталог, сложная логика и интеграции, бюджет смещается к 3-6 млн рублей.

Личный кабинет или веб-сервис чаще оценивается в 3-8 млн. MVP корпоративного портала — 4-8 млн. Полноценный портал с ролями, документами, внутренними процессами и интеграциями — 8-20 млн. Высоконагруженные системы и цифровые экосистемы начинаются примерно от 15-20 млн рублей.

Это не прайс. Это порядок бюджета для заказной разработки.

Ключевой вопрос не в том, сколько страниц будет у сайта. Важно, какие процессы он поддерживает, какие данные обрабатывает, какие внешние системы подключает и как должен работать при сбоях.

Где заканчивается сайт и начинается портал

Граница проходит не по размеру интерфейса.

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

На этом уровне трудоемкость смещается с визуальной части на серверную логику, данные и интеграции.

Например, пользователь видит один и тот же экран. Но один пользователь может видеть только свои заявки, второй — заявки подразделения, третий — сводные данные, четвертый — настройки и справочники. В интерфейсе это несколько кнопок и фильтров. В системе — отдельная логика прав, фильтрации, аудита и обработки исключений.

Чем больше пересечений между ролями, тем быстрее растет сложность.

Почему интерфейс не показывает объем работ

Самая частая ошибка при оценке — судить по тому, что видно на экране.

Например, подборщик смазочных материалов для пользователя выглядит как несколько полей: марка автомобиля, модель, год выпуска и тип двигателя.

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

Внешне это небольшой блок сайта. По объему работ — самостоятельный цифровой сервис.

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

Если подрядчик оценивает только удачный сценарий, смета будет ниже. Если он сразу закладывает обработку ошибок, журналирование, повторные попытки и восстановление обмена, смета станет выше. Но вторая оценка ближе к промышленной эксплуатации.

Как интеграции меняют смету

Строка «интеграция с CRM» почти ничего не говорит о трудоемкости.

В одном случае сайт просто отправляет форму в готовый метод API. В другом — система синхронизирует несколько сущностей, получает статусы, обрабатывает ограничения внешнего сервиса и восстанавливает обмен после сбоя.

На бумаге обе работы могут называться одинаково. В оценке это разные объемы.

Особенно рискованны интеграции с legacy-системами. Документация может быть неполной, API может отсутствовать, а реальные правила обмена известны только внутренней команде заказчика. Тогда часть проекта превращается в исследование существующего контура.

Точная оценка без доступа к интерфейсам, примерам данных и ограничениям внешней системы в таких случаях невозможна. Можно дать диапазон и зафиксировать допущения. Но выдавать точную сумму до исследования — значит переносить риск на этап разработки.

Почему миграция редко бывает простой

С миграцией часто возникает та же проблема.

На старте кажется, что данные нужно просто перенести из старой системы в новую. Потом выясняется, что справочники не совпадают, форматы менялись несколько раз, связи повреждены, часть записей дублируется, а часть давно неактуальна.

Техническое копирование — самая простая часть миграции.

Основная работа начинается раньше: нужно понять, какие данные нужны новой системе, как они соотносятся с новой моделью, какие записи считать корректными и кто принимает результат переноса.

Если в смете учтен только импорт, реальный объем появится после старта. И почти всегда он окажется больше ожидаемого.

Как эксплуатационные требования влияют на архитектуру

Две системы могут иметь одинаковые функции, но стоить по-разному из-за требований к эксплуатации.

Есть сайт, который можно восстановить за несколько часов. Есть портал, остановка которого блокирует продажи, обслуживание клиентов или внутренние операции.

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

Это не «перестраховка». Это стоимость ответственности за работу системы после запуска.

Чем дороже простой, тем выше требования к разработке, тестированию, инфраструктуре и поддержке.

Что должно быть в оценке подрядчика

Хорошая оценка показывает не только итоговую сумму. Она объясняет, какой продукт подрядчик понял, какие границы проекта зафиксировал и какие допущения использовал.

Важно видеть, как подрядчик понял роли пользователей, пользовательские сценарии, интеграции, миграцию, эксплуатационные требования и зону своей ответственности.

Если одна команда отвечает только за код, а другая — за промышленный запуск и гарантийный период, это разные предложения. Их нельзя сравнивать только по итоговой цене.

То же относится к ставке. Низкая часовая ставка не гарантирует низкий бюджет. Команда со ставкой 2 500 рублей может оценить задачу в 400 часов, а команда со ставкой 4 000 рублей — в 200 часов. В первом случае итог будет 1 млн рублей, во втором — 800 тыс.

Сравнивать нужно не ставку, а трудозатраты, состав результата и ответственность.

Как сравнивать предложения

Предложения на 3 и 6 млн рублей можно сравнивать только после декомпозиции.

Сначала нужно понять, одинаково ли подрядчики трактуют границы системы. Затем посмотреть, какие роли и сценарии учтены, как описаны интеграции, кто отвечает за внешние системы, включена ли миграция, какие требования к эксплуатации заложены и что считается готовым результатом.

Если разница сохраняется, стоит попросить команды показать оценку по функциональным блокам. Обычно после этого видно, что один подрядчик не учел часть работ, предложил другую архитектуру или оставил существенные задачи на стороне заказчика.

Низкая цена часто означает не экономию, а перенесенный риск.

Вывод для рынка

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

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

Корректный вопрос к подрядчику звучит не «сколько стоит сайт на 30 страниц».

Точнее спросить: сколько стоит система с такими пользователями, сценариями, данными, интеграциями и требованиями к надежности?

Пока эти параметры не определены, любая цена остается предварительной.