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

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

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

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

Содержание

Сколько стоит сайт или портал

Что означают ценовые диапазоны

Чем сайт отличается от портала

Как рассчитывается объем работ

Из чего складывается бюджет

Что входит в ставку подрядчика

Какие расходы могут остаться за пределами сметы

Почему стоимость меняется после старта

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

Какой бюджет закладывать на проект

Сколько стоит разработка сайта или портала

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

Это практические ориентиры для заказной разработки, а не универсальный прайс.

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

Что означают эти диапазоны

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

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

Например, корпоративный сайт за 1,5 млн рублей может состоять из информационных разделов, форм и стандартной CMS. Проект за 5-6 млн рублей уже способен включать каталог, несколько источников данных, сложный поиск, персонализированные результаты и отдельные инструменты для администраторов.

Визуально оба решения могут выглядеть похожими. Разница находится внутри.

То же относится к MVP портала. MVP не означает «сделать максимально дешево, а ошибки исправить потом». Это минимальный набор законченных сценариев, который можно безопасно запустить, проверить на пользователях и развивать без полной переделки системы.

Чем сайт отличается от портала

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

Портал становится рабочим инструментом. Пользователь выполняет операции, а система управляет данными, правами и внутренними процессами.

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

Лендинг или промосайт

Такой ресурс создают для отдельного продукта, услуги, рекламной кампании или мероприятия.

Основной бюджет приходится на дизайн, верстку, контент и формы. Цена растет, если нужны сложная анимация, интерактивные элементы, калькуляторы, 3D или несколько внешних сервисов.

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

Корпоративный сайт

Корпоративный сайт представляет компанию, продукты и экспертизу.

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

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

Каталог или интернет-магазин

В каталоге появляется товарная логика: характеристики, фильтры, цены, остатки, заказы, оплата и доставка.

Основная сложность часто скрывается в обмене с 1С, ERP, складскими и логистическими системами.

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

Личный кабинет или корпоративный портал

С этого уровня речь идет уже о полноценном веб-приложении.

В него могут входить:

• личные кабинеты;
• документы;
• заявки;
• согласования;
• внутренние сервисы;
• отчетность;
• CRM, ERP и 1С;
• единая авторизация;
• сложная модель ролей;
• журналы действий.
  
  

Количество страниц здесь отходит на второй план. Бюджет определяют процессы, данные, интеграции и требования к надежности.

Как рассчитывается объем работ

Оценка начинается не с подсчета страниц и кнопок.

Иногда самый скромный элемент интерфейса оказывается самостоятельным цифровым сервисом.

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

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

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

Пользователи и права

Сначала нужно понять, кто будет работать в системе.

Это могут быть посетители, клиенты, партнеры, редакторы, операторы, руководители и администраторы.

Для каждой роли определяются доступные данные и действия. Один пользователь видит только собственные заявки. Другой работает со всем подразделением. Третий утверждает документы. Четвертый меняет настройки системы.

На макете эта сложность почти незаметна. В программном коде она затрагивает практически каждый раздел.

Пользовательские сценарии

Затем команда разбирает, что именно сможет сделать пользователь.

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

Одна кнопка превращается в работу для аналитика, дизайнера, frontend-разработчика, backend-разработчика и тестировщика.

Интеграции

Для каждой внешней системы нужно определить:

• какие данные передаются;
• в каком направлении идет обмен;
• как часто он запускается;
• есть ли документированный API;
• что происходит при ошибке;
• кто отвечает за вторую сторону интеграции.
  
  

Подключение к современной системе с готовым API может занять несколько дней. Работа с устаревшим решением без документации иногда растягивается на месяцы.

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

Данные и миграция

Старые данные редко готовы к автоматическому переносу.

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

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

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

Надежность и безопасность

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

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

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

Из чего складывается бюджет проекта

Упрощенно бюджет запуска можно представить так:

Трудозатраты команды + лицензии и инфраструктура + внешние сервисы + резерв на известные риски.

Техническая поддержка и дальнейшее развитие обычно рассчитываются отдельно.

Сайт или портал создают аналитики, дизайнеры, frontend- и backend-разработчики, тестировщики, DevOps-инженеры и менеджеры.

Аналитика: определить систему до разработки

До аналитики заказчик часто видит проект как набор разделов и функций. После разбора процессов становится понятно, сколько ролей, данных и внешних систем скрывается за этой формулировкой.

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

По итогам аналитики заказчик получает:

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

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

Дешевле всего исправлять процесс до начала разработки.

Интерфейс: спроектировать все состояния

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

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

Затем frontend-разработчик превращает макеты в работающий интерфейс, подключает API, реализует формы, фильтры, поиск и обработку ошибок.

На экране пользователь видит один результат. Команда должна предусмотреть все пути, которыми он может к нему прийти.

Серверная часть: реализовать процессы и данные

Backend скрыт от пользователя. Именно там портал принимает решения, проверяет права, выполняет расчеты и связывается с внутренними системами.

Серверная часть:

• хранит данные;
• управляет авторизацией;
• проверяет права;
• выполняет бизнес-правила;
• формирует документы;
• отправляет уведомления;
• взаимодействует с API;
• фиксирует действия пользователей;
• управляет административными модулями.
  
  

Для информационного сайта backend может ограничиваться CMS и несколькими формами.

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

Тестирование и запуск: проверить всю цепочку

Готовый код еще не означает готовую систему.

Проверять нужно не отдельные экраны, а полные сценарии: от авторизации пользователя до передачи данных во внешнюю систему и возврата результата.

Команда тестирует:

• функции;
• роли и права;
• API;
• интеграции;
• мобильные устройства;
• браузеры;
• производительность;
• безопасность;
• работу системы после обновлений.
  
  

Ошибка в информационном блоке портит впечатление. Ошибка в правах доступа может открыть пользователю чужие документы. Сбой интеграции способен остановить бизнес-процесс.

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

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

Управление проектом

Аналитик описывает процесс. Дизайнер переводит его в интерфейс. Разработчики реализуют логику. Тестировщик проверяет всю цепочку.

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

Руководитель проекта:

• планирует работы;
• координирует команду;
• фиксирует решения;
• контролирует сроки и бюджет;
• управляет рисками;
• организует демонстрации;
• ведет приемку;
• обрабатывает изменения.
  
  

В сложных проектах управление нередко составляет около 10-15% трудозатрат. Конкретная доля зависит от размера команды, количества участников со стороны заказчика и сложности согласований.

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

Из чего складывается ставка компании

Ставку подрядчика нельзя напрямую сравнивать с зарплатой штатного разработчика.

В нее входят:

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

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

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

В 2026 году ставки профессиональных команд веб-разработки обычно находятся в диапазоне от 2 500 до 5 000 рублей в час. Работа архитектора, ведущего аналитика или senior-разработчика может стоить дороже.

Но выбирать подрядчика только по ставке неправильно.

Команда со ставкой 2 500 рублей может потратить на задачу 400 часов. Команда со ставкой 4 000 рублей решит ее за 200 часов. Во втором случае итоговая стоимость окажется ниже.

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

Что может не входить в первоначальную оценку

Даже подробное коммерческое предложение не всегда покрывает все расходы.

Перед заключением договора стоит проверить, учтены ли:

• подготовка и перенос контента;
• очистка исторических данных;
• лицензии CMS;
• серверная инфраструктура;
• карты, SMS и рассылки;
• доработка API внешних систем;
• нагрузочное тестирование;
• аудит безопасности;
• техническая документация;
• обучение сотрудников;
• круглосуточная поддержка;
• дальнейшее развитие.
  
  

Например, в смете есть строка «интеграция с CRM», но доработка самой CRM туда не входит. Разница обнаруживается уже после старта.

Формально интеграция учтена. Фактически часть работ остается на стороне заказчика или оплачивается дополнительно.

Поэтому сравнивать нужно не только общую сумму. Сначала следует проверить границы ответственности каждой команды.

Почему стоимость может измениться после старта

Цена остается стабильной, пока не меняются требования и исходные условия.

Появились новые функции

Новая функция требует не только программирования. Ее нужно описать, спроектировать, реализовать и проверить.

Даже небольшое изменение интерфейса может затронуть базу данных, административную панель и внешние системы.

Уточнился бизнес-процесс

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

Формально речь все еще идет об одной заявке. По факту объем логики увеличивается.

Обнаружились ограничения интеграции

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

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

Данные оказались неготовыми

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

Появляется отдельный блок очистки и преобразования данных, которого не было в первоначальной оценке.

Изменились требования к безопасности

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

Это влияет на архитектуру, разработку и тестирование.

Сократились сроки

Ускорение проекта требует расширения команды и параллельного выполнения работ.

Такой режим увеличивает нагрузку на управление и повышает риск повторных согласований.

Любое изменение цены должно быть связано с конкретным изменением объема или исходных условий.

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

Техническая поддержка после запуска

Запуск завершает создание первой версии. После него начинается эксплуатация.

Даже информационный сайт нужно обновлять, контролировать и защищать.

В поддержку могут входить:

• мониторинг;
• устранение ошибок;
• обновление компонентов;
• резервное копирование;
• контроль безопасности;
• сопровождение интеграций;
• консультации пользователей;
• выпуск новых версий;
• работа с инцидентами.
  
  

Небольшой сайт можно поддерживать за 30-100 тыс. рублей в месяц.

Для сложного корпоративного ресурса с регулярным развитием бюджет обычно начинается от 150-400 тыс. рублей в месяц.

Для бизнес-критичного портала с круглосуточным SLA, мониторингом и несколькими линиями поддержки годовая стоимость может начинаться от 3,5 млн рублей.

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

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

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

Проверьте:

1. Включена ли аналитика.
2. Кто готовит требования и техническое задание.
3. Какие пользовательские сценарии учтены.
4. Сколько ролей будет в системе.
5. Какие интеграции входят в оценку.
6. Кто отвечает за качество и миграцию данных.
7. Какие виды тестирования проводятся.
8. Входит ли настройка серверов.
9. Какая документация передается.
10. Что включено в гарантию.
11. Сколько итераций согласования предусмотрено.
12. Как рассчитываются изменения.
    
    

Низкая цена часто означает, что часть работ вынесена за границы предложения.

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

Какой бюджет закладывать на проект

Бюджет до 1,5 млн рублей обычно предполагает типовое решение с ограниченной индивидуальной логикой.

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

При бюджете 3-6 млн рублей можно планировать сложный корпоративный ресурс, каталог или систему с нестандартной административной частью.

С диапазона 4-8 млн рублей начинается территория личных кабинетов и первых версий корпоративных порталов.

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

Поэтому корректный запрос подрядчику звучит не так:

«Сколько стоит сайт на 30 страниц?»

Точнее спросить:

«Сколько стоит система с такими пользователями, процессами, интеграциями и требованиями к надежности?»

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

Команда «Энсайн» может провести предпроектный анализ, определить границы системы и подготовить обоснованную оценку разработки.