Ошибка при выборе исполнителя обычно обходится дороже, чем разница между самым дешёвым и самым дорогим предложением из короткого списка: доработки, повторное тестирование, а иногда и полная переделка после смены команды стоят больше, чем экономия на старте.
Эти риски можно снизить до начала разработки — без юридического образования и знания кода. Дальше по порядку: какие есть форматы работы, что подготовить до поиска, где смотреть кандидатов, как их проверить, как сравнивать предложения и что прописать в договоре, чтобы результат и права на него остались у вас.
Фрилансер, студия, агентство или своя команда
У каждого формата свои сильные стороны и свои риски. Выбор зависит не столько от бюджета, сколько от сложности проекта, срока и от того, нужно ли развивать приложение годами или требуется разовый релиз.
| Формат | Подходит для | Плюсы | Риски | Кто управляет проектом |
|---|---|---|---|---|
| Фрилансер | Простое приложение на одну платформу, MVP, доработка продукта | Ниже стоимость часа, прямое общение, гибкий график | Один человек — один риск: болезнь, занятость на другом проекте, нет резерва компетенций | Заказчик — ставит задачи и решает сам |
| Небольшая студия (5–20 человек) | Проект среднего масштаба, если нужна команда из нескольких ролей | Есть менеджер, тестировщик, обычно замена на каждой роли | Меньше запас прочности, чем у агентства; качество зависит от конкретной команды внутри студии | Проект-менеджер студии, решения по продукту — заказчик |
| Крупное агентство | Сложный или высоконагруженный продукт, корпоративные интеграции, жёсткие сроки | Формализованный процесс, аналитик и архитектор на входе, устойчивость | Выше стоимость часа, меньше гибкости, задача может уйти менее опытной части команды | Отдельный менеджер со стороны агентства |
| Своя штатная команда | Продукт, который развивается годами и является ядром бизнеса | Полный контроль, знания о продукте остаются внутри компании | Высокий порог входа: наём, адаптация, простой между релизами | Заказчик как работодатель |
| Аутстафф | Расширение команды заказчика конкретными ролями на срок проекта | Быстрее найма в штат, работа по процессам заказчика | Специалисты формально не в штате; нужен свой руководитель, который ими управляет | Заказчик, нужен свой тимлид |
Часто выбирают не один формат на весь проект, а комбинацию: студия делает MVP, а поддержку и развитие берёт на себя штатный специалист. Это нормально, если заранее прописаны условия передачи кода и доступов (раздел «Что прописать в договоре»).
Что подготовить до поиска подрядчика
Чем меньше деталей в задаче, тем сильнее предложения кандидатов будут отличаться друг от друга — не потому что кто-то завышает цену, а потому что каждый представляет себе разный продукт. Минимальный набор до начала поиска:
- Бриф или ТЗ — цели, пользователи и ключевые сценарии. Структура и примеры формулировок — в статье «Техническое задание на мобильное приложение». Для первого контакта достаточно версии на одну-две страницы, полное ТЗ можно дописать вместе с выбранной командой.
- Бюджетная рамка — не точная сумма, а диапазон. Без неё исполнители либо предлагают избыточный вариант, либо режут важные функции, не спрашивая вас.
- Критерии выбора — что важнее: цена, скорость запуска, опыт в вашей нише, смежные роли (дизайнер, аналитик) в команде. Без этого решение принимается по последнему разговору, а не по сравнению.
- Одинаковый список вопросов для всех кандидатов, чтобы предложения можно было сопоставить (раздел «Как сравнивать предложения»).
Если готового ТЗ нет, это тоже рабочая отправная точка: многие студии и опытные фрилансеры помогают довести бриф до ТЗ на предпроектном этапе. Другое дело — когда исполнитель просит согласиться на разработку вовсе без описания функций: здесь риск расхождения ожиданий резко растёт.
Где искать кандидатов и как составить короткий список
Универсального «лучшего» источника нет — качество исполнителя определяется не тем, откуда он пришёл, а результатом проверки на следующем этапе. Разумно смотреть сразу в нескольких направлениях:
- Рекомендации знакомых предпринимателей. Самый надёжный источник — можно спросить не только «понравилось ли», но и как прошла сдача, были ли просрочки.
- Рейтинги и каталоги студий разработки. Помогают быстро составить список кандидатов, но верхние позиции в них нередко платные — относитесь к рейтингу как к источнику имён для проверки, а не как к готовому вердикту о качестве.
- Профильные сообщества по мобильной разработке — там видны реальные доклады и код команд, а не только маркетинговые материалы.
- Профили специалистов на площадках для фрилансеров — важнее количества отзывов, совпадает ли опыт с вашей задачей: платформа, ниша, масштаб.
Из первичного списка в 8–15 имён до подробного разговора и коммерческого предложения стоит доводить 3–5 кандидатов: меньше — не с чем сравнивать, больше — время уходит на переговоры вместо проекта.
Как проверить исполнителя перед стартом
Проверка занимает один-два дня, но именно здесь видно расхождение между презентацией и тем, как команда работает на самом деле.
- Установите готовые приложения из портфолио. Не ограничивайтесь скриншотами на сайте — скачайте два-три релиза. Обратите внимание на дату последнего обновления (без обновлений больше года — сигнал, что команда не сопровождает свои же проекты), на рейтинг и на реакцию разработчика на отзывы.
- Поговорите с прежними клиентами. Попросите один-два контакта заказчиков со схожими проектами и спросите не только про качество кода, но и про соблюдение сроков и реакцию на правки после сдачи.
- Уточните, кто конкретно будет работать над проектом. В презентации часто показывают самых опытных сотрудников, а к задаче подключают других. Спросите имена, роли и опыт людей, которые сядут за ваш проект.
- Обсудите процесс работы. Демонстрации раз в одну-две недели, тестовые сборки на реальных устройствах, доступ к трекеру задач — это должен предложить сам исполнитель, а не отдавать по требованию.
- Посмотрите, какие вопросы задаёт вам исполнитель. Опытная команда на первой встрече спрашивает про аудиторию, бюджет, интеграции и сроки. Если вопросов нет, а сразу называют цену — вероятно, оценивали шаблонное решение.
- Проверьте юридическое лицо. Бесплатный сервис ФНС «Прозрачный бизнес» (pb.nalog.ru) показывает данные из ЕГРЮЛ/ЕГРИП, а картотека арбитражных дел kad.arbitr.ru — судебные споры компании. Это не заменяет разговор с клиентами, но помогает отсеять однодневки.
Как сравнивать коммерческие предложения
Сравнивать предложения по итоговой сумме бессмысленно, если под одной цифрой у разных исполнителей скрывается разный объём работы. Чтобы получить сопоставимые оценки:
- Отправьте всем кандидатам один и тот же документ — бриф или ТЗ — и просите оценку именно по нему, а не «в общих чертах по телефону».
- Просите декомпозицию по ролям и этапам: сколько часов аналитики, дизайна, разработки на каждой платформе, бэкенда, тестирования и менеджмента заложено в оценку.
- Уточняйте, что включено в цену, а что нет — часто за скобками остаются аккаунты в сторах, платные сервисы (карты, SMS, пуш) и период поддержки после сдачи.
- Спрашивайте про запас на риски. Оценка без резерва на доработки обычно означает, что перерасход оформят допсоглашением уже после старта.
Подробно о том, из чего вообще складывается стоимость и какие статьи расходов часто забывают включить в смету, — в статье «Сколько стоит разработка мобильного приложения» (раздел «Как читать коммерческое предложение»). Если рассматриваете и нативную, и кроссплатформенную разработку, стоит заранее задать кандидатам вопросы о выборе технологии — они перечислены в статье «Нативная или кроссплатформенная разработка».
Что прописать в договоре
Договор — это не формальность для бухгалтерии, а инструмент, который решает споры до того, как они возникли. Ниже — пункты, которые стоит проверить в любом договоре на разработку, независимо от формата исполнителя.
| Пункт | Зачем нужен | Что проверить |
|---|---|---|
| Предмет договора и ТЗ как приложение | Фиксирует, что именно считается выполненной работой | ТЗ или его актуальная версия прикреплены к договору, а не существуют «в переписке» |
| Этапы и критерии приёмки | Позволяет платить и проверять результат частями, а не одной суммой в конце | У каждого этапа есть измеримый результат и срок сдачи, а не только процент оплаты |
| Исключительные права на код и дизайн | Определяет, кому принадлежит результат после сдачи | Прямо указано, что исключительное право переходит заказчику (договор об отчуждении, ст. 1234 ГК РФ), а не остаётся у исполнителя с выдачей лицензии (ст. 1235 ГК РФ) |
| Передача исходников и доступов | Без этого пункта «код передан» может означать что угодно | Прописаны конкретные каналы передачи: репозиторий с полной историей коммитов, аккаунты в App Store/Google Play/RuStore — на организацию заказчика, домены и серверы — на заказчика или с полным доступом заказчика |
| Гарантия и поддержка | Разграничивает бесплатное исправление ошибок и платные доработки | Указан срок гарантии и что в неё входит; про дальнейшее сопровождение — статья «Поддержка приложения после релиза» |
| Порядок изменения объёма работ | Проекты почти всегда меняются в процессе — вопрос в том, как это оформлено | Есть процедура допсоглашения с оценкой стоимости и срока изменения, а не устные договорённости |
| Конфиденциальность и обработка персональных данных | Актуально, если приложение собирает данные пользователей | Есть пункт о неразглашении и, если применимо, поручение на обработку персональных данных (подробнее — в статье «Персональные данные в мобильном приложении») |
| Ответственность и расторжение | Определяет, что происходит при просрочке или срыве проекта | Прописаны санкции за нарушение сроков и условия одностороннего расторжения с сохранением уже оплаченного и переданного результата |
По умолчанию, если договор прямо не оговаривает иное, согласно ст. 1296 ГК РФ исключительное право на программу для ЭВМ, созданную по заказу, принадлежит заказчику, а исполнитель сохраняет право использовать код только для собственных нужд по безвозмездной простой лицензии. Это не повод обходиться без письменного договора: устная договорённость или переписка в мессенджере плохо доказывают сам факт «создания по заказу» и условия сделки в случае спора. Разница между договором об отчуждении права (ст. 1234 ГК РФ — право переходит заказчику полностью) и лицензионным договором (ст. 1235 ГК РФ — заказчик получает только право использования, а не собственность на результат) должна быть в тексте прямо, а не подразумеваться.
Это не юридическая консультация. Формулировки договора и распределение прав зависят от конкретной ситуации — перед подписанием стоит показать документ юристу.
Красные флаги при выборе подрядчика
Ни один из перечисленных признаков сам по себе не означает мошенничество, но каждый — повод задать дополнительные вопросы или продолжить поиск.
- Цена заметно ниже остальных предложений без внятного объяснения, что именно исключено из объёма работ.
- Исполнитель называет итоговую сумму, не задав ни одного вопроса про аудиторию, сценарии и ограничения проекта.
- Требование стопроцентной предоплаты за весь проект целиком, а не за первый этап.
- Аккаунты в сторах, репозиторий или домен изначально регистрируются на исполнителя «для удобства», без чёткого обязательства передать их заказчику.
- Отказ показывать промежуточные тестовые сборки до самого конца разработки — «увидите готовый результат».
- Формулировки вроде «исходный код передадим после оплаты годовой поддержки» — де-факто это удержание результата, за который уже заплачено.
- Нет доступа к трекеру задач или переписке с командой — общение только через одного менеджера, который «передаёт всё разработчикам».
- Договор существует только в устной форме или ограничивается счётом на оплату без описания предмета и условий.
- Портфолио состоит только из скриншотов без ссылок на живые приложения в сторах.
- Резкое давление на скорость принятия решения — «цена действует только сегодня».
Как работать с подрядчиком после старта
Даже тщательный выбор не отменяет необходимости управлять проектом дальше. Несколько практик снижают риск того, что процесс «уйдёт в тишину» на месяцы:
- Один ответственный со стороны заказчика. Решения по продукту принимает конкретный человек, а не группа с разными мнениями — иначе исполнитель получает противоречивые указания.
- Регулярные демонстрации. Раз в одну-две недели — показ рабочей версии, а не отчёт в переписке. Так быстрее заметить расхождение с ожиданиями, пока его дёшево исправить.
- Доступ к репозиторию с первого дня, а не после сдачи. Это не вопрос недоверия, а стандартная практика, которая ничего не стоит исполнителю и защищает заказчика.
- Оплата по этапам с привязкой к результату, а не к календарным датам — так у обеих сторон остаётся стимул завершать этап полностью.
Если нужно сменить подрядчика
Смена команды в середине проекта — крайняя мера, но иногда неизбежная. Дороже всего обходится не оплата новой команде, а время на то, чтобы она разобралась в чужом коде. Что помогает снизить потери:
- Заберите всё, что положено по договору — полный репозиторий с историей коммитов, доступы к сторам, серверам и сторонним сервисам, документацию, если она велась.
- Закажите независимый аудит кода у новой команды до согласования сроков и стоимости дальнейшей работы — оценка «на глаз» почти всегда занижает объём работы по разбору чужой архитектуры.
- Учитывайте, что смена команды стоит дороже, чем кажется: новой команде нужно время не только на код, но и на восстановление контекста незадокументированных решений. Поэтому пункт о передаче исходников и доступов экономит деньги при любом сценарии, включая тот, где сотрудничество проходит без проблем.
Частые вопросы
Стоит ли просить у подрядчика тестовое задание перед стартом проекта?
Небольшое оплачиваемое тестовое задание на 1–2 дня — разумный способ увидеть качество кода и коммуникации до подписания договора. Требовать бесплатную объёмную работу «для отбора» не стоит: серьёзные исполнители на это чаще всего не соглашаются.
Можно ли работать с фрилансером совсем без договора?
Формально можно, но это увеличивает риски для обеих сторон: без письменного договора сложнее доказать, что именно заказано, в какой срок и на каких условиях передаются права на результат. Даже простой договор на одну-две страницы заметно снижает эти риски.
Кому по умолчанию принадлежит код, если в договоре ничего не написано про права?
Если из договора видно, что работа выполнялась по заказу на создание программы, по ст. 1296 ГК РФ исключительное право по умолчанию принадлежит заказчику. Но полагаться на «умолчание» рискованно: точная формулировка договора надёжнее общего правила, поэтому договор всё равно стоит показать юристу.
Как лучше платить — сразу всю сумму или по этапам?
Оплата по этапам с привязкой к проверяемому результату каждого этапа — стандартная и безопасная практика. Небольшой аванс на первый этап — это нормально, а требование оплатить всю сумму сразу за весь проект — повод насторожиться.
Стоит ли брать подрядчика из другого города или страны?
Удалённость команды сама по себе не риск — мобильная разработка почти всегда ведётся удалённо. Важнее разница часовых поясов для связи, юрисдикция для договора и то, насколько прозрачны у команды процессы отчётности.
Нужен ли заказчику свой технический специалист, если нанят подрядчик?
Для небольшого разового проекта можно обойтись без него. Для среднего и крупного проекта, особенно при развитии продукта годами, приглашённый технический консультант, способный оценить код со стороны заказчика, заметно снижает риск того, что результат некому проверить, кроме самого исполнителя.
Чек-лист выбора подрядчика
- Есть бриф или ТЗ, бюджетная рамка и критерии выбора до начала поиска
- В коротком списке 3–5 кандидатов, а не один «понравившийся с первого разговора»
- Установлены и проверены живые приложения из портфолио каждого кандидата
- Есть контакт хотя бы одного прежнего клиента для каждого финалиста
- Все кандидаты оценивали один и тот же документ, предложения декомпозированы по ролям и этапам
- Юрлицо проверено через «Прозрачный бизнес» и картотеку арбитражных дел
- В договоре прямо прописан переход исключительных прав на код и дизайн заказчику
- Прописан порядок передачи репозитория, доступов к сторам, серверам и доменам
- Оплата разбита на этапы с проверяемым результатом, а не выплачивается одной суммой
- Договор перед подписанием показан юристу
Итог
Формат работы — фрилансер, студия, агентство или своя команда — стоит выбирать под масштаб и горизонт проекта, а не по абстрактному рейтингу «что лучше». Гораздо сильнее на результат влияет то, насколько тщательно проверен конкретный кандидат: живые приложения в сторах, разговор с прежними клиентами, прозрачный процесс с демонстрациями и доступом к репозиторию с первого дня.
Договор — это не бюрократия, а страховка от самых дорогих сценариев: потери прав на код, невозможности сменить команду и споров о том, что вообще входило в объём работ. Несколько дней, потраченных на проверку исполнителя и внимательное чтение договора, стоят на порядок дешевле, чем переделка проекта с нуля после неудачного выбора.