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

Заказ приложения почти всегда начинается одинаково: находят пять студий, собирают пять коммерческих предложений и сравнивают только по стоимости. Так выбирать нельзя. Разброс в сметах достигает трёх раз, и дешёвое предложение обычно означает не экономию, а другой объём работ.

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

Наличие сайта, блога и кейсов по веб-проектам не равно опыту в мобильной разработке. Это разные команды, разные инструменты и разные грабли.

Смотрите, что уже опубликовано в App Store и Google Play. Не скриншоты в презентации, а живые приложения: скачайте, откройте, посмотрите отзывы и дату последнего обновления. Приложение, которое не обновлялось два года, скорее всего, брошено. Приложение с оценкой 4+ и ответами разработчика на отзывы — хороший знак: команда живёт с продуктом после релиза.

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

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

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

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

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

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

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

И последнее про деньги: сравнивайте не стоимость запуска, а стоимость владения за два года. Приложение, которое дешевле собрать и дороже поддерживать, обгоняет конкурента по расходам уже на втором году жизни.

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

Внутри бюджета пропорции обычно такие: разработка забирает 50–60%, дизайн 15–25%, остальное — аналитика, тестирование и управление проектом. Если в смете дизайн занимает половину, а тестирование отсутствует, это не дешевле — это другой продукт.

Полезно понимать порядок цифр, чтобы отличать адекватную смету от фантазии. Средняя ставка разработчика на российском рынке в 2026 году — около 3 500 рублей в час. Простое приложение с одной ролью и парой экранов начинается примерно от 700 тысяч рублей, MVP с платежами и админкой — от 800–1000 тысяч, сложное решение с интеграциями в корпоративные системы уходит за несколько миллионов.

Приложение не заканчивается релизом. Дальше — обновления систем, изменения правил сторов, ошибки на реальных устройствах, новые функции.

Закладывайте на поддержку 15–20% от стоимости разработки в год. Если в предложении этой строки нет, спросите прямо: что происходит после сдачи, сколько стоит час доработок, какая реакция на критичную ошибку в проде. Ответ «обсудим потом» означает, что обсуждать вы будете в позиции слабой стороны.

Уточните гарантию. Нормальная практика — шесть месяцев бесплатного исправления ошибок в рамках сданного объёма. Границы должны быть в договоре, иначе каждый баг превратится в спор, ошибка это или новая хотелка.

И самое дорогое, что можно упустить: код и доступы. Репозиторий должен быть вашим с первого дня, а команда подрядчика имеет к нему доступ, а не наоборот. Аккаунты в App Store и Google Play оформляются на вашу компанию, даже если технически их заводит подрядчик. То же с сервером, доменом, платёжным провайдером и аналитикой.

Красный флаг — отказ показать код текущих проектов или дать контакты клиентов. Ссылка на NDA понятна, но тогда должен найтись хотя бы один пример, который показать можно. Полная закрытость обычно означает, что показывать нечего.

Проект на несколько месяцев — это не сделка, а совместная работа. Способ общения влияет на результат сильнее, чем ставка за час.

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

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

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

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

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

И последний: обещание «сделаем сразу под все платформы и магазины». iOS, Android, RuStore и AppGallery различаются правилами публикации и требованиями к сборкам. Команда, которая говорит об этом как о мелочи, скорее всего, ни разу не публиковалась дальше одного стора.

В приложении «Нужные Люди» мы проходили ровно этот путь: сервис подбора исполнителей с двумя ролями в одном приложении, платежами и админкой собрали за восемь месяцев.

Этап аналитики занял первые недели и оказался самой недооценённой частью. Две роли — заказчик и исполнитель — это два разных сценария входа, две ленты, разные права и разная логика уведомлений. Если не проговорить это до дизайна, половину экранов придётся переделывать.

Дальше подключили платежи и подписки, собрали админку для управления контентом, прошли публикацию в обоих сторах. За первые полгода после запуска MVP зарегистрировалось больше 25 000 человек. Эта цифра появилась не из-за красивого дизайна, а потому что на старте выбрали один понятный сценарий вместо десяти.

Четыре пункта, которые снимают большую часть будущих споров:

Передача прав на код и исходники, доступ к репозиторию с каждым подписанием акта, аккаунты в сторах на вашу компанию.

Критерии приёмки: перечень сценариев, которые должны проходить на тестовых данных. «Работает» критерием не является.

Процедура изменений: кто инициирует, кто оценивает, в какой срок и как фиксируется согласие.

Условия выхода: что происходит при досрочном расторжении, какие материалы передаются и в каком виде.

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

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

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

Что делать, если бюджет ограничен?

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

Студия или фрилансер?

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

Нужно ли техническое задание до выбора подрядчика?

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

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

Мы в Else Digital делаем мобильные приложения для iOS и Android, начинаем с аналитики и технического задания и берём на себя публикацию в сторах. Если нужна не команда под ключ, а усиление вашей — это аутстаффинг мобильных разработчиков. Как мы работаем на длинной дистанции, видно в кейсе «Нужные Люди».