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

Компания потратила четыре месяца и 1,8 млн рублей на разработчика, который сдал продукт с критическими дырами в безопасности и без документации. Ситуация типичная — не потому что рынок плохой, а потому что критерии выбора подрядчика по разработке сводились к двум вопросам: «Сколько стоит?» и «Когда сделаете?»…

Этап 1. Формализация задачи до первого разговора с подрядчиком

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

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

Этап 2. Оценка портфолио: на что смотреть, а не просто «смотреть»

Портфолио — не галерея скриншотов. Для оценки подрядчика по разработке важны три конкретных вещи: живые продукты (можно потрогать руками), измеримые результаты (не «повысили конверсию», а «с 1,2% до 3,4% за 90 дней после релиза») и наличие кейсов в смежной вам отрасли. Продукт для ритейла и продукт для b2b SaaS — разные архитектурные решения, разные требования к нагрузке.

Попросите контакт клиента из портфолио для короткого звонка. Нормальный подрядчик без колебаний даст референса. Спрашивайте не «всё ли понравилось», а конкретно: были ли срывы сроков, как команда вела себя при обнаружении критических багов после сдачи, есть ли документация на переданный код. Эти три вопроса дают больше, чем час презентации.

Ориентировочный фильтр по объёму опыта: если вы планируете проект на 3–6 месяцев и бюджет от 2 млн рублей, ищите команду с не менее чем тремя завершёнными проектами сопоставимого масштаба — не по деньгам, а по сложности функционала.

Этап 3. Технический аудит команды — даже если вы не технарь

Вам не нужно разбираться в архитектуре микросервисов, чтобы задать правильные вопросы. Попросите подрядчика рассказать, как они будут решать вашу задачу: какой стек, почему именно он, как организовано code review, есть ли CI/CD-процессы и нагрузочное тестирование перед релизом. Не важно, понимаете ли вы каждое слово — важно, насколько уверенно и структурированно команда объясняет свои решения.

Если у вас есть возможность привлечь независимого технического консультанта на один звонок — сделайте это. Стоимость такой консультации в 2026 году составляет от 15 000 до 40 000 рублей в зависимости от экспертизы специалиста. Это вложение окупается многократно: опытный технарь за 60 минут выявит то, что вы не заметите за три встречи.

Этап 4. Договор и структура оплаты как индикатор зрелости подрядчика

Зрелый подрядчик предложит поэтапную оплату, привязанную к конкретным deliverables, а не к календарным датам. Типичная структура: 20–30% предоплата, далее оплата по закрытым этапам с приёмкой. Если вам предлагают схему «50% сейчас, 50% после сдачи» без промежуточных точек контроля — это риск, особенно на проектах длиннее двух месяцев.

Обратите внимание на то, что прописано в договоре относительно: прав на исходный код (они должны переходить к вам полностью), гарантийного обслуживания (разумный минимум — 3 месяца на исправление дефектов без дополнительной оплаты), порядка изменения требований (без регламента по change request любой каприз заказчика превращается в инструмент давления с обеих сторон).

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

Этап 5. Пилотный спринт как финальный фильтр

Если масштаб проекта позволяет, запустите платный пилотный спринт — обычно 2–3 недели работы с ограниченным scope. Это может быть разработка одного модуля, прототип ключевого экрана или технический proof of concept для самой рискованной части задачи. Стоимость пилота должна быть соразмерна объёму: от 150 000 до 400 000 рублей для типовых задач.

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

Вывод

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

В Tech Wave мы работаем с заказной разработкой и понимаем эти вопросы с обеих сторон. Если у вас есть задача и вы хотите пройти по описанным этапам вместе — расскажите нам о проекте, обсудим, чем можем быть полезны.