Запрос «сколько стоит доработать сайт на Битрикс» похож на вопрос о стоимости ремонта помещения: без площади, состояния и требований точная цифра будет случайной. Даже внешне небольшая задача — добавить поле в заказ, изменить форму или передать заявку в CRM — может затронуть шаблон, компонент, события, обмен и ранее написанный код.
В 2026 году логика оценки не изменилась: подрядчик продаёт не строку кода, а время на понимание системы, реализацию, проверку и безопасный выпуск. На этом сайте публичный базовый ориентир для доработок — от 2500 ₽ в час. Это ставка, а не обещание конкретной стоимости проекта. Итоговый объём определяется после разбора задачи и текущей реализации.
Почему одинаковые формулировки дают разный объём
Два бизнеса могут попросить «добавить фильтр по бренду». На одном сайте бренды уже хранятся в едином свойстве, используется стандартный умный фильтр и актуальный шаблон. На другом названия разбросаны по нескольким полям, часть каталога приходит из 1С, шаблон фильтра изменён предыдущим подрядчиком, а кеш обновляется непредсказуемо. Для пользователя результат похож, но путь к нему различается.
На оценку влияют не только функции, но и исходное состояние:
- редакция и версия 1С-Битрикс, PHP и окружения;
- качество и расположение кастомного кода;
- наличие репозитория и истории изменений;
- тестовый контур, резервное копирование и способ выпуска;
- зависимости от 1С, CRM, оплаты, доставки и внешних API;
- полнота требований и количество согласующих;
- требования к миграции существующих данных;
- объём регрессионного тестирования.
Поэтому предложение назвать фиксированную сумму по одному абзацу не всегда выгодно заказчику. Подрядчик либо закладывает большой резерв на неизвестность, либо даёт привлекательную цифру, которую позже пересматривает.
Из каких работ состоит оценка
1. Погружение и диагностика
Разработчик выясняет, где реализован текущий сценарий, какие данные участвуют и нет ли конфликтующих доработок. Для знакомого типового проекта это короткий этап. Для сайта без документации он может стать отдельной задачей с самостоятельным результатом: картой компонентов, найденными рисками и вариантами реализации.
Диагностика — не «плата за то, чтобы открыть код». Она снижает вероятность, что новая функция будет построена на неверном предположении. В кейсе Dom hub работа с уже созданным сайтом началась с аудита разделов, компонентов и шаблонов, а изменения внедрялись поэтапно, не затрагивая стабильные части.
2. Проектирование решения
Нужно определить источник данных, точки расширения и поведение при ошибках. Для простого интерфейсного изменения проектирование может занимать несколько заметок. Для интеграции — схему полей, правила повторов, защиту от дублей, хранение токенов и журнал операций.
На этом этапе часто обнаруживается более дешёвый путь: настройка вместо разработки, использование события вместо изменения компонента или поэтапный MVP вместо полной автоматизации.
3. Реализация
Это собственно программирование, настройка и, при необходимости, подготовка миграций. Часы реализации зависят от числа сценариев и исключений, а не от количества экранов. Один административный обработчик, который безопасно меняет заказы, может быть сложнее нескольких информационных страниц.
4. Тестирование
Проверяется не только «счастливый путь». Важны пустые значения, повторная отправка, разные права, мобильный интерфейс, недоступность внешнего сервиса и сохранение прежних сценариев. Чем ближе функция к оплате, заказам, доступу или остаткам, тем выше цена ошибки и тем больше нужен объём проверки.
5. Выпуск и наблюдение
Даже готовый код требуется перенести на рабочий сайт, применить настройки, очистить или прогреть кеш, проверить журналы. Для рискованных изменений нужен план отката. После запуска иногда предусматривают период наблюдения — особенно для фоновых заданий и интеграций, поведение которых видно только на реальном потоке.
6. Документация и передача
Описание настроек, новых событий, cron-задач и зависимостей уменьшает стоимость будущей поддержки. Исключение документации из оценки делает текущую задачу дешевле только на бумаге: следующий специалист снова оплачиваемо восстанавливает контекст.
Почасовая или фиксированная оценка
Почасовой формат подходит для диагностики, очереди небольших задач и проектов с высокой неопределённостью. Заказчик оплачивает фактическое время, а приоритеты можно менять. Чтобы формат оставался контролируемым, полезны предварительный диапазон часов, ограничение на этап и отчёт о сделанном.
Фиксированная стоимость уместна, когда требования и критерии приёмки достаточно стабильны. Исполнитель принимает часть риска оценки, поэтому в цену обычно входит резерв. Фикс не означает, что любые новые пожелания автоматически входят в договорённость: границы задачи должны быть записаны.
Оценка по этапам сочетает оба подхода. Сначала оплачивается диагностика или прототип, затем фиксируется следующий блок. Это особенно полезно для чужого кода и интеграций: бизнес не принимает решение о всём бюджете до получения технических данных.
Что сильнее всего увеличивает неопределённость
Главный фактор — неизвестные зависимости. Если изменение формы влияет на самописную CRM-интеграцию, это должно войти в проверку. Если каталог обновляется из 1С, нельзя менять свойства, не выяснив правила обмена.
Другие источники риска:
- правки ядра или файлов стороннего решения;
- отсутствие тестовой копии и актуального бэкапа;
- несколько реализаций одного сценария;
- неясный владелец справочника или поля;
- требования «должно работать как раньше, но иначе» без примеров;
- внешнее API без тестовой среды и документации;
- необходимость преобразовать исторические данные;
- выпуск в жёсткое окно без возможности отката.
Такие факторы не означают, что проект плохой. Они означают, что оценку следует разбить и сначала купить информацию.
Как подготовить запрос и получить сопоставимые предложения
Вместо фразы «нужна доработка личного кабинета» подготовьте короткий бриф:
- Ссылка на сайт, редакция и версия платформы, если известны.
- Описание текущего сценария по шагам.
- Желаемый сценарий и бизнес-причина изменения.
- Роли пользователей и различия в правах.
- Источники и получатели данных.
- Примеры входных данных и ожидаемого результата.
- Интеграции, которые могут быть затронуты.
- Критерии приёмки: как проверить, что задача решена.
- Ограничения по срокам и допустимому простою.
- Наличие тестового контура, репозитория и доступов.
Макеты полезны для интерфейса, но не заменяют описание правил. Фраза «кнопка видна менеджеру после оплаты и недоступна при возврате» влияет на оценку больше, чем её цвет.
Как читать оценку подрядчика
Хорошая оценка показывает состав работ и допущения. В ней понятно, включены ли анализ, тестирование, выкладка и исправление обнаруженных регрессий. Если указан диапазон, должно быть объяснено, что приблизит результат к верхней границе.
Задайте пять вопросов:
- Какие данные пока неизвестны?
- Что именно будет результатом этапа?
- Что не входит в оценку?
- Как согласуются дополнительные работы?
- Как будет проверяться и выпускаться изменение?
Сравнивать предложения только по итоговой цифре некорректно. Один исполнитель мог включить тестовый контур и документацию, другой — только написание кода. Приведите состав к общему знаменателю.
Как уменьшить стоимость без ущерба качеству
Самый эффективный способ — сократить не тесты, а неопределённость и объём первого релиза. Отделите обязательные сценарии от удобных дополнений. Дайте доступ к репозиторию, предыдущим задачам и документации. Назначьте одного человека, который принимает решения по правилам бизнеса.
Для крупной функции сформируйте MVP: один тип пользователя, один источник данных, основные статусы. Но MVP должен быть эксплуатационно полноценным: с правами, обработкой ошибок и возможностью диагностики. «Сделаем без логов, а потом добавим» — не экономия для интеграции.
Не стоит просить исполнителя экономить за счёт правок на рабочем сайте без тестирования. Цена потенциального сбоя в заказах обычно выше нескольких часов подготовки.
Почему нельзя публиковать универсальный прайс на проекты
Публично можно честно указать ставку или цену стандартной услуги с чёткими границами. Нельзя достоверно заявить, что «интеграция стоит X», если неизвестны системы, поля и правила. Поэтому здесь используется только базовый ориентир от 2500 ₽/час, а не выдуманные цены типовых проектов.
Это не мешает планировать бюджет. После первичного брифа можно определить, нужна ли короткая оценка, платная диагностика или декомпозиция по этапам. Чем выше неопределённость, тем меньше должен быть первый оплачиваемый шаг.
Итог: покупайте управляемый процесс оценки
Стоимость доработки складывается из состояния проекта, сложности правил, рисков интеграций и требований к безопасному запуску. Ставка помогает пересчитать трудозатраты в деньги, но не заменяет диагностику.
Если нужно оценить действующий сайт, подготовьте описание сценария и доступный технический контекст. На странице доработки чужого проекта на 1С-Битрикс можно отправить задачу для первичного разбора. Практичный результат первого контакта — не обещание цены «на глаз», а понятный следующий этап, его границы и способ получить обоснованную оценку.