Как выбрать подрядчика для разработки сайта на Битриксе и не получить проблемный проект

Найти разработчика на Битрикс несложно — гораздо сложнее найти такого, который сделает сайт качественно, в срок и за адекватные деньги, а потом не пропадёт после запуска. Битрикс — специфичная CMS, и подрядчики отличаются между собой настолько сильно, что один и тот же проект у одних будет стоить 300 тыс. и сделают за месяц, у других — 1.5 млн и через год переделают. Разберём 12 критериев, на которые стоит смотреть при выборе.

1. Сертификация 1С-Битрикс

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

На что смотреть: статус «Партнёр», «Золотой партнёр», «Платиновый партнёр» — это разные уровни. Список сертификатов разработчиков — проверяется на сайте 1c-bitrix.ru. Это не гарантия качества, но «голден стандарт» — если у компании нет ни одного сертифицированного разработчика, это красный флаг.

2. Опыт именно в вашем сегменте

Студия может быть отличной в лендингах, но никогда не делала магазины с обменом 1С. Или наоборот — спецы по крупным интернет-магазинам, но корпоративный сайт с дизайн-системой им никогда не давался. Не верьте универсалам.

Что спрашивать: «Покажите 3 проекта вашего опыта, похожих на нашу задачу — по типу, размеру и сложности интеграций». Если в ответ показывают 5 разных по типу проектов — это либо случайный выбор, либо нет специализации.

3. Реальные кейсы (не «работы»)

Кейс — это не «вот мы сделали сайт». Кейс — это «была задача, мы предложили такое решение, сделали так-то, получился такой-то измеримый результат». Хорошие подрядчики умеют рассказывать про свои проекты с цифрами, проблемами, ограничениями.

Красный флаг: «у нас 200 проектов, но мы не можем рассказывать из-за NDA». Один-два под NDA — нормально. Все 200 под NDA — повод задуматься.

4. Возможность связаться с действующими клиентами

Самый честный способ — попросить контакт 2–3 клиентов, для которых подрядчик делал похожие проекты в последние 1–2 года. Не «отзывы на сайте», а реальный звонок или встреча с владельцем бизнеса или маркетологом, кто работал с этим подрядчиком.

Вопросы: сделали ли в срок? уложились ли в бюджет? как поддерживали после запуска? появлялись ли скрытые работы и доплаты? Если подрядчик не даёт контакты ни одного клиента — это серьёзный сигнал.

5. Прозрачная команда

Сколько человек работает над проектом? Кто именно: сеньор-разработчик, миддл, джуниор? Кто менеджер? Кто дизайнер? Это люди в штате или фрилансеры?

Опасный паттерн: «мы команда из 10 человек», а на проекте по факту работает один разработчик-миддл, остальные «помогают по мере возможности». Просите познакомить с командой проекта на пресейле.

6. Понятный процесс

Хороший подрядчик умеет внятно объяснить, что и как будет происходить:

• Этап 1 — аналитика и ТЗ (1–3 недели), что выходит на этом этапе.
• Этап 2 — дизайн, прототипы, утверждение макетов.
• Этап 3 — разработка, по итерациям.
• Этап 4 — тестирование и стейджинг.
• Этап 5 — релиз и поддержка.

У каждого этапа должны быть сроки, бюджеты, артефакты (что вы получаете на выходе) и точки приёмки. Если вместо этого «давайте начнём, по ходу разберёмся» — почти гарантированно затянутся сроки и вырастет бюджет.

7. Качество ТЗ и оценки

Дайте подрядчику бриф и попросите подготовить предварительную оценку. Хороший подрядчик задаст 30+ уточняющих вопросов, прежде чем дать цифру. Слабый — сразу скажет «1.2 млн, давайте начнём».

В оценке должны быть: разбивка по этапам и видам работ, оценка трудоёмкости в часах, ставки специалистов, риски и допущения. Если оценка — одна цифра без объяснений, это не оценка, это «договоримся на словах».

8. Кодовая база и техническая зрелость

Спросите: «Покажите, как вы организуете код в /local/ Битрикса. Используете ли вы Git? Composer? Какие инструменты для деплоя?»

Хорошие подрядчики обязательно используют:

• Git с понятной веткой ветками (main/dev/feature).
• Стейджинг + продакшн (минимум 2 окружения).
• Деплой через скрипты или CI/CD, а не «по FTP».
• Composer для управления зависимостями.
• Code review перед слиянием в main.
• Структуру кода в /local/ (а не правки ядра!).
• Логирование и мониторинг.

Если в ответ «мы пишем как удобно, файлы кладём через WinSCP» — это означает, что через год сайт будет адом для поддержки.

9. Договор и юридические детали

Договор должен включать:

• Чёткое описание объёма работ (по разделам, не «разработка сайта»).
• Сроки этапов с точными датами.
• Стоимость по этапам, условия оплаты.
• Гарантийные обязательства после релиза (минимум 3 месяца, лучше 6).
• Передача всех исходников, доступов, документации.
• Право собственности на код и дизайн — за заказчиком.
• Условия расторжения и возврата оплаты.
• Штрафные санкции за просрочку (хотя бы для крупных проектов).
• NDA, если нужен.

Если предлагают работать «без договора, по доверию» — отказывайтесь сразу, как бы дёшево ни казалось. Это путь к проблемам.

10. Поддержка после релиза

Что будет с сайтом после запуска? Кто его будет поддерживать? Какие условия? Если подрядчик не предлагает чёткую модель поддержки (а просто «обращайтесь, если что») — велик риск, что через полгода с поддержкой будут проблемы.

Хороший вариант: пакеты поддержки на 6–12 месяцев включаются в договор разработки с фиксированной ставкой и SLA. Подробно про техподдержку — в отдельной статье.

11. Цена

Странный пункт, но важный: подозрительно низкая цена — самый частый «красный флаг». Если все подрядчики дают оценку 1–1.5 млн, а один говорит «300 тыс.» — почти гарантированно: либо они недооценивают (и ваш проект превратится в долгую агонию), либо реализуют через джуниоров (и качество будет страдать), либо всплывут «допработы» на ту же сумму.

Адекватная вилка для проекта одного класса — обычно отличается между подрядчиками в 1.5–2 раза. Если разница в 5 раз — что-то не так. Берите среднюю цену, не самую низкую.

12. Способность сказать «нет»

Хороший подрядчик иногда возражает: «Это решение неудачное, давайте сделаем иначе». Подрядчик, который соглашается со всеми вашими идеями, — либо хочет понравиться (и потом будет переделывать), либо не имеет своего экспертного мнения.

На пресейле дайте им заведомо спорную задачу («хочу мерцающий баннер на всех страницах») и посмотрите реакцию. Адекватный подрядчик объяснит, почему это плохая идея, и предложит альтернативу.

Чек-лист собеседования

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

• Покажите 3 кейса по похожим проектам с цифрами и описанием.
• Дайте контакт 2 действующих клиентов для общения.
• Кто конкретно будет работать в нашем проекте? Познакомьте с командой.
• Как вы организуете разработку: Git, окружения, деплой?
• Какова ваша оценка по этапам и часам?
• Что входит в гарантийный период и сколько он длится?
• Какая модель поддержки после релиза?
• Что будет, если вы превысите оценку?
• Что будет, если мы захотим сменить подрядчика — как передаются доступы и код?
• Сертифицированы ли ваши разработчики 1С-Битрикс?

Красные флаги

Срочно ищите другого подрядчика, если:

• Не дают контакты действующих клиентов.
• Сразу называют цену без анализа задачи.
• Цена в 3+ раза ниже рынка.
• Хотят 100% предоплату.
• Не показывают портфолио, только «у нас 200 проектов».
• Не используют Git и стейджинг.
• Готовы начать «уже завтра» без ТЗ.
• Отказываются прописать гарантии в договоре.
• Не дают исходники после оплаты.

Что в итоге

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

Если хотите обсудить ваш проект — напишите нам. На пресейле мы открыто рассказываем, как работаем, показываем кейсы, знакомим с командой и даём детальную оценку с разбором по этапам.