Как заказать разработку мобильного приложения: выбор подрядчика и договор

Между решением «нам нужно приложение» и подписанным договором лежит шесть шагов: сформулировать бизнес-задачу и метрику успеха, собрать короткий бриф, отобрать пять-семь подрядчиков по портфолио в вашей нише, провести созвоны и сократить список до трёх, получить сопоставимые коммерческие предложения на одинаковом объёме, проверить договор в части прав на код, аккаунтов и приёмки.

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

Шаг 1. Что подготовить до первого письма

Готовое ТЗ не требуется — его вам помогут написать. Но без ответов на эти вопросы разговор будет пустым.

Какую бизнес-задачу решает приложение. Не «у конкурентов есть», а «хотим сократить долю заказов через колл-центр» или «нужен канал повторных продаж».

Что должно измениться и на сколько. Выручка, средний чек, удержание, скорость обработки заявки, объём ручной работы. Эта метрика потом определит, какие функции войдут в первый релиз, а какие уйдут в бэклог.

Кто пользователи. Конкретно: не «женщины 25–45», а «мама, которая заказывает вечером с телефона, пока ребёнок спит», или «курьер, который работает в полях с нестабильным интернетом».

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

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

Кто принимает решения. Один человек с правом финального «да». Проекты, где требования правят трое, срываются по срокам чаще всего.

Шаг 2. Где искать

Отраслевые рейтинги и каталоги. Рейтинг Рунета, Tagline, CMS Magazine, Workspace. Читать их нужно правильно: смотреть не общее место, а профильную номинацию и живые проекты в вашей нише. Позиция отражает в том числе активность компании в самом рейтинге, а не только качество работы.

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

Профессиональные площадки. Хабр, профильные Telegram-каналы, конференции. Компании, публикующие технические разборы, обычно готовы отвечать за сказанное.

Рекомендации. Самый надёжный канал, но проверяйте, что проект был сопоставим по масштабу. Хорошая студия для лендинга не обязательно потянет продукт с интеграциями.

Аккредитация Минцифры — формальный, но полезный фильтр: подтверждает, что перед вами IT-компания, а не посредник.

Шаг 3. Форматы работы

Формат

Плюсы

Минусы

Кому подходит

Студия под ключ

Полная команда, ответственность за результат

Дороже фриланса

Большинству: продукт нужен, своей команды нет

Фрилансеры

Дёшево

Нет тестирования, аналитики, менеджмента

Простые задачи, точечные доработки

Аутстафф

Гибкость, люди в вашем управлении

Нужен свой руководитель проекта

Есть внутренняя техническая экспертиза

Своя команда

Полный контроль, знания остаются внутри

Найм 3–6 месяцев, постоянный ФОТ

Продукт — ядро бизнеса на годы

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

Шаг 4. Категории студий: кого выбирать под свой бюджет

Известные студии. Больше десяти лет на рынке, федеральные бренды в портфолио, верхние строчки рейтингов. Работают с проектами от нескольких миллионов; небольшой заказ им неинтересен, и вы это почувствуете уже по скорости ответа на заявку.

Средние компании. Пять–десять лет, смешанное портфолио от крупных клиентов до средних проектов. Основная масса рынка и оптимальный выбор для большинства задач: экспертиза есть, ценник адекватный, ваш проект будет для команды заметным.

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

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

Шаг 5. Типовое решение или разработка с нуля

Развилка, которую полезно пройти до сравнения смет.

Типовое решение — приложение, собранное из готовых модулей и настроенное под ваш бренд. Каталог, корзина, оплата, личный кабинет, push уже есть; вам достаются оформление, настройка и интеграции. Дешевле и быстрее, подходит небольшой рознице, доставке, салонам. Ограничения: меньше свободы в логике, часть решений зависит от платформы поставщика. Отдельно выясните, что происходит с приложением, если вы перестанете платить подписку, и остаётся ли у вас код.

Разработка с нуля нужна, когда бизнес-логика нестандартная, есть глубокие интеграции с вашими системами или продукт — ядро бизнеса, а не витрина. Дороже и дольше, но результат полностью ваш и масштабируется без оглядки на чужие ограничения.

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

Шаг 6. Двенадцать вопросов на первом созвоне

Хороший подрядчик сам задаёт больше вопросов, чем отвечает. Но эти двенадцать стоит задать вам.

1. Какие проекты вы делали в нашей отрасли и что там оказалось сложным?
2. Какую метрику, по-вашему, должно двигать наше приложение?
3. Какой стек вы рекомендуете и почему именно его?
4. Как вы оцениваете проект — по часам, ролям, этапам?
5. Кто конкретно будет в команде и заняты ли эти люди сейчас на других проектах?
6. Как организована коммуникация: как часто демо, в каком канале, кто наш менеджер?
7. Что вы делаете, когда объём работ выходит за смету?
8. Как устроено тестирование и на скольких реальных устройствах?
9. Кому принадлежит исходный код и как выглядит его передача?
10. На чьё юрлицо оформляются аккаунты в магазинах приложений?
11. Какая гарантия после релиза и что в неё входит?
12. Можно ли поговорить с двумя вашими клиентами?

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

Шаг 7. Как сравнить три коммерческих предложения

Главная проблема сравнения в том, что предложения приходят на разный объём работ и потому несопоставимы. Разброс в пять-десять раз означает не разницу в жадности, а разницу в том, что каждый заложил.

Дайте всем одинаковые вводные. Идеально — одно ТЗ, полученное на отдельном этапе аналитики. Минимум — одинаковый бриф со списком функций.

Требуйте разбивку. Часы по ролям и этапам. Норма загрузки разработчика — 120–140 часов в месяц: из этого проверяется, сходится ли заявленная команда с заявленным сроком.

Проверьте структуру бюджета. Здоровое распределение: аналитика 10–15%, дизайн 15–25%, разработка 50–60%, тестирование 10–15%, менеджмент 10–15%. Если разработка съела 90%, остальное просто не заложено.

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

Посмотрите на резерв. 10–15% — норма и признак честности. Ноль — риски переложены на вас. Тридцать и больше — завышение.

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

Реалистичная разница между адекватными предложениями — до 30%. Если одно вдвое дешевле двух других, ищите, чего в нём нет.

Шаг 8. Форматы оплаты

Фиксированная стоимость. Вы знаете сумму заранее, подрядчик несёт риск переработок и потому закладывает в смету запас 20–40%. Подходит при понятном объёме и согласованном ТЗ.

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

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

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

Шаг 9. Права на код, аккаунты и данные

Раздел, который обсуждают реже всего, а он определяет, останетесь ли вы владельцем продукта.

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

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

Ключи подписи и сертификаты. Хранятся у вас. Без них другая команда не сможет выпустить обновление вашего же приложения.

Серверы и домены. На вашу компанию, с доступами у вас.

Дизайн-макеты. Исходные файлы, а не экспортированные картинки.

Документация. Описание архитектуры, спецификации API, инструкции по сборке и развёртыванию. Без них следующая команда потратит месяц на разбор.

Данные пользователей. Кто является оператором персональных данных, где они хранятся, что происходит при расторжении договора.

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

Шаг 10. Приёмка: как не подписать «то, что получилось»

Критерии оговариваются до начала работ, а не на финише.

• Приёмка по этапам, а не одна в конце. Каждый этап закрывается актом с конкретным результатом: прототип, макеты, сборка с работающим модулем.
• Критерий — соответствие ТЗ. Не «нравится» и не «работает», а «функция реализована в описанном объёме».
• Тестирование на ваших устройствах и ваших данных. Реальный каталог, реальные пользователи, реальные сценарии. На трёх выдуманных позициях не видно ничего.
• Список дефектов с приоритетами. Критические и серьёзные исправляются до подписания, косметические могут уйти в гарантийный период.
• Гарантия. Обычно от одного до шести месяцев на исправление ошибок, возникших по вине подрядчика. Уточните, что считается гарантийным случаем, а что — новой доработкой.

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

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

Частые вопросы

Сколько времени занимает выбор подрядчика?

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

Нужно ли готовое ТЗ, чтобы обратиться в студию?

Нет. Достаточно бизнес-задачи, понимания аудитории и списка систем, с которыми приложение должно работать. ТЗ подрядчик готовит на этапе аналитики, часто отдельным договором.

Сколько подрядчиков запрашивать?

Оптимально три. Один не даёт точки сравнения, семь превращают выбор в отдельный проект.

Можно ли платить по этапам?

Да, это стандартная практика: аванс, затем оплата по закрытым этапам. Полная предоплата — редкость и повод задать вопросы.

Что делать, если приложение уже есть, но им занимался другой подрядчик?

Начните с аудита кода: новая команда оценивает состояние проекта, архитектуру и объём технического долга. По итогам становится ясно, дешевле развивать существующее или переписать.

Обязательно ли выбирать студию из своего города?

Нет. Разработка давно распределённая, география влияет разве что на удобство часовых поясов. Важнее опыт в вашей нише и прозрачность процессов.

Что делать, если подрядчик перестал выходить на связь?

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