Как выбрать подрядчика на разработку

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

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

С чего начать: задача до подрядчика

Сравнивать исполнителей без описания задачи бесполезно: каждый оценит свою версию продукта, и цены будут отличаться в разы. До рассылки запросов подготовьте хотя бы короткое ТЗ на 2–4 страницы:

• цель продукта и метрика успеха;
• роли пользователей и ключевые сценарии;
• обязательные функции первой версии;
• интеграции (CRM, 1С, оплаты, склад);
• требования к данным и размещению;
• бюджетная вилка и срок, к которому продукт нужен.

Одинаковое ТЗ, отправленное 4–6 кандидатам, превращает выбор из угадывания в сравнение. Пошаговая структура и пример — в статье как составить техническое задание на разработку.

Фрилансер или студия разработки

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

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

Чек-лист: 12 пунктов для выбора исполнителя

Этот список одинаково полезен, если вы решаете, как выбрать студию разработки для платформы или частного разработчика для бота. Отмечайте каждый пункт по шкале «да / частично / нет».

1. Релевантные кейсы. Не «красивые картинки», а проекты похожей сложности: роли, интеграции, нагрузка. Попросите показать работающий продукт, а не только скриншоты.
2. Люди, которые будут делать проект. Кто конкретно ведёт архитектуру, кто пишет код, будет ли у вас прямой контакт с разработчиками или только с менеджером.
3. Процесс. Как часто демо, есть ли тестовый стенд, где видна доска задач. Нормальный ответ — демо каждую неделю и стенд с первых недель.
4. Вопросы к вам. Сильный подрядчик задаёт много неудобных вопросов о бизнесе и метриках. Если оценку прислали через час без единого вопроса — это оценка чего-то другого.
5. Структура оценки. Смета разбита на этапы и функции, видны допущения и риски, а не одна цифра «под ключ».
6. Права на код. В договоре прямо указано, что исключительные права на результат переходят к вам, а репозиторий находится на вашем аккаунте.
7. Размещение. Продукт разворачивается на ваших серверах или в вашем облаке, домены и доступы оформлены на вас.
8. Безопасность. Как хранятся секреты и доступы, кто имеет доступ к продакшену, как обрабатываются персональные данные по 152-ФЗ.
9. Качество кода. Есть ли код-ревью, автотесты, CI/CD, мониторинг ошибок. Попросите показать фрагмент кода или провести технический созвон с вашим экспертом.
10. Документация и передача. Что вы получите на выходе: описание архитектуры, инструкцию по развёртыванию, доступы, обучение команды.
11. Поддержка после запуска. Есть ли SLA: время реакции на критичную ошибку, часы работы, стоимость часа доработок.
12. Рекомендации. Возможность поговорить с одним-двумя прошлыми клиентами — лучший способ проверить всё перечисленное выше.

Если кандидат набирает «нет» по пунктам 6, 7 и 10, остальное почти не важно: даже хороший продукт окажется заложником отношений с одной командой.

Права на код и где размещается продукт

Это самый недооценённый раздел. Типичная история: продукт работает, но размещён на сервере подрядчика, домен зарегистрирован на его сотрудника, а репозитория у вас нет. Смена команды в такой ситуации превращается в переговоры.

Что зафиксировать

• Отчуждение исключительного права на программный код и дизайн в вашу пользу — по актам, поэтапно или по итогам проекта.
• Перечень используемых сторонних компонентов и их лицензий: open source-библиотеки с «заразными» лицензиями могут ограничить коммерческое использование.
• Репозиторий (GitHub, GitLab или ваш собственный) создан на аккаунте вашей компании, подрядчик работает в нём как приглашённый участник.
• Облако, серверы, домены, аккаунты разработчика в App Store и Google Play, платёжные кабинеты — оформлены на ваше юрлицо.
• Передача включает документацию, переменные окружения, схему инфраструктуры и инструкцию по развёртыванию.

Договор, оплата и SLA

Модель оплаты влияет на поведение обеих сторон. Две основные схемы:

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

Приёмка и гарантия

Пропишите, как принимается каждый этап: по чек-листу сценариев из ТЗ, на тестовом стенде, с фиксированным сроком на замечания (например, 5 рабочих дней). Отдельно оговорите гарантийный период после запуска — обычно от одного до трёх месяцев, — в течение которого подрядчик бесплатно исправляет ошибки в сделанном функционале. Важно различать ошибку («кнопка оплаты не работает в Safari») и новое требование («давайте добавим оплату частями»): второе оплачивается как изменение объёма.

Поддержка по SLA

SLA на поддержку обычно описывает: классы инцидентов (критичный, серьёзный, мелкий), время реакции и восстановления для каждого, часы работы (рабочее время или 24/7), способ эскалации и стоимость доработок вне поддержки.

Красные флаги на первой встрече

• Оценка без вопросов и без проработки — «сделаем за 2 недели», ещё не поняв задачу.
• Цена в 2–3 раза ниже остальных кандидатов на одно и то же ТЗ без объяснения, за счёт чего.
• Отказ показать работающие продукты или дать контакт хотя бы одного клиента.
• «Код передаём после полной оплаты», «хостинг только у нас», «домен оформим на себя, так удобнее».
• Никто из разработчиков не участвует во встречах — только менеджер продаж.
• Одинаковый стек для любой задачи: и боту, и маркетплейсу, и AI-системе предлагают одно и то же.
• Нет ответа на вопрос «что будет, если через год мы захотим сменить подрядчика».

Как выбрать веб-студию: вопросы для встречи

Если вы думаете, как выбрать веб-студию для сайта или веб-приложения, добавьте к общему чек-листу специфические вопросы:

1. Какие показатели скорости у ваших последних сайтов? Можно проверить в PageSpeed Insights прямо на встрече.
2. Как закладываете техническое SEO: микроразметка, sitemap, канонические адреса, скорость?
3. Какая CMS и насколько удобно менять контент без разработчика?
4. Как устроена аналитика: цели, события, связка с CRM?
5. Что входит в поддержку и сколько стоит час доработок после запуска?

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

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