Сколько стоит сайт на заказ в 2026: из чего складывается реальная смета

1. Почему “сколько стоит сайт?” - неправильный первый вопрос

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

В 2026 году рынок стал менее терпим к “красивым, но пустым” сайтам. Компании хотят, чтобы сайт быстрее грузился, корректно индексировался, был готов к рекламному трафику, передавал лиды в CRM, давал аналитику, выдерживал изменения контента и не ломался при первом обновлении. Поэтому серьезная смета описывает не страницы, а пакеты работ и критерии готовности.

Если подрядчик называет цену через две минуты после фразы “нам нужен сайт”, это не оценка, а ставка на то, что детали всплывут позже. Хорошая смета начинается с вопросов.

2. Диапазоны цен на рынке РФ в 2026

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

3. Work package: аналитика, UX и прототипирование

Аналитика и UX - это не “поговорили на созвоне”. Это превращение бизнес-задачи в структуру продукта: аудитории, сценарии, карта страниц, пользовательские пути, контентная модель, события аналитики, ограничения интеграций, критерии приемки. Для простого лендинга этап может занимать 1-2 недели. Для портала - 3-6 недель и больше, потому что нужно описать роли, статусы и исключения.

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

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

Хороший UX-этап уменьшает смету разработки не всегда, но почти всегда уменьшает стоимость ошибок. Это особенно заметно в проектах с личными кабинетами и интеграциями.

4. Work package: визуальный дизайн и дизайн-система

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

Стоимость дизайна растет не только от количества экранов, но и от количества состояний. Кнопка “Оплатить” в макете - это одно. Оплата в реальности имеет ожидание, ошибку, отмену, успешный статус, повтор, чек, уведомление и поддержку. Если эти состояния не прорисованы, они все равно появятся в разработке, только позже и дороже.

5. Work package: frontend-разработка

Frontend отвечает за то, что пользователь видит и ощущает: скорость, адаптивность, интерактивность, формы, доступность, SEO-разметку, локализацию, работу с данными и качество интерфейсных состояний. В 2026 году “сверстать макет” недостаточно. Нужно контролировать Core Web Vitals, корректно загружать изображения и шрифты, не ломать индексацию, поддерживать компоненты и писать код, который можно развивать.

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

• Компоненты, layout, адаптивная сетка.
• Формы, валидация, маски, отправка заявок.
• SEO: мета-теги, заголовки, Schema.org, canonical, hreflang при необходимости.
• Производительность: изображения, шрифты, lazy loading, bundle size.
• Интерфейсные состояния: загрузка, ошибка, пустые данные, успех.

6. Work package: backend, CMS и бизнес-логика

Backend появляется там, где сайт перестает быть только витриной. Нужно хранить заявки, управлять пользователями, выдавать роли, принимать оплаты, синхронизировать данные, создавать документы, вести историю действий, обеспечивать админку и API. Именно backend часто объясняет, почему “похожий визуально” проект стоит существенно дороже.

CMS тоже бывает разной. Иногда достаточно простого редактирования текстов и изображений. Иногда нужна ролевая редактура, черновики, публикации по расписанию, версии, SEO-поля, мультиязычность, справочники, связи между сущностями и ограничения доступа. Чем ближе CMS к внутреннему продукту, тем больше она похожа на отдельную систему.

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

7. Work package: интеграции

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

Интеграция “отправить заявку в CRM” может занять несколько часов, если есть готовый API и простые поля. Но если нужно синхронизировать статусы, товары, счета, оплаты, документы и права менеджеров, это уже отдельный проектный блок. Нормальная смета должна показывать количество направлений обмена и правила обработки ошибок.

• CRM: лиды, сделки, статусы, ответственные, UTM-метки.
• 1С: номенклатура, счета, остатки, контрагенты, документы.
• Платежи: создание платежа, вебхуки, чеки, возвраты, ошибки.
• Рассылки: подписки, сегменты, транзакционные уведомления.
• Внешние API: лимиты, подписи, ретраи, мониторинг.

8. Work package: DevOps, инфраструктура и релиз

DevOps - это не “залить сайт на хостинг”. Для серьезного проекта нужны окружения, переменные, секреты, CI/CD, SSL, домены, резервные копии, мониторинг, логирование, алерты, защита от простых сбоев и понятный план отката. Чем больше бизнес зависит от сайта, тем меньше допустим подход “если что, поправим на сервере руками”.

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

9. Скрытые расходы: где бюджет уезжает после старта

Скрытые расходы почти всегда связаны не с “жадностью подрядчика”, а с незафиксированной ответственностью. Кто пишет тексты? Кто готовит фотографии? Кто согласует юридические формулировки? Кто дает доступы к CRM? Кто принимает решения, если интеграция работает не так, как ожидали? Если это не описано, сроки и бюджет начинают двигаться.

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

• Подготовка и редактура текстов.
• Миграция контента и SEO-редиректы.
• Покупка лицензий, шрифтов, изображений, сервисов.
• Доработки после тестирования на реальных данных.
• Обучение администраторов и документация.
• Сопровождение после релиза и исправление инцидентов.

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

10. Как студии оценивают проекты

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

Есть три распространенные модели: фиксированная цена за четко описанный объем, time & materials для проектов с изменяющимися требованиями и поэтапная модель, где первый этап уточняет архитектуру и смету следующих. Для сайтов и порталов часто лучше работает поэтапность: она сохраняет контроль бюджета и не заставляет подрядчика закладывать огромный риск в первый договор.

11. Красные флаги в коммерческих предложениях

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

Другой красный флаг - обещание “любой функционал входит” при фиксированной цене. В реальности это приводит либо к конфликту, либо к падению качества. Зрелая команда спокойно говорит, что входит в первый релиз, что является опцией, а что требует отдельной оценки после discovery.

• В смете нет этапов и артефактов.
• Интеграции описаны одной строкой без сценариев ошибок.
• Не указаны адаптив, производительность, SEO и аналитика.
• Нет тестирования и staging-окружения.
• Нет условий поддержки после запуска.
• Подрядчик не задает вопросов о процессе и данных.

12. Контекст тарифов Enginx: 150k, 500k и индивидуальная оценка

Наши ориентиры 150 тысяч, 500 тысяч и индивидуально не являются попыткой упаковать все проекты в три коробки. Это способ быстро объяснить уровень сложности. Формат от 150 тысяч подходит для сфокусированных лендингов и промо-страниц, где важны скорость, аккуратный дизайн, адаптивность, базовое SEO и формы заявок. Формат от 500 тысяч - для корпоративных сайтов и более плотной структуры: несколько типов страниц, мультиязычность, CMS, аналитика, SEO-логика, интеграции заявок.

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

Здоровая смета не всегда самая низкая. Здоровая смета объясняет, за что вы платите, какие риски закрыты и что произойдет после первого релиза.