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

По данным отраслевых отчётов о состоянии мобильного рынка, пользователи проводят в приложениях большую часть экранного времени, а расходы на них исчисляются сотнями миллиардов долларов в год. При этом аналитики Gartner не раз отмечали, что доля проектов разработки, которые срываются по срокам или бюджету, остаётся высокой — и мобильные приложения не исключение. Чаще всего причина не в технологиях, а в неправильно выбранной команде. Разберём, как выбрать подрядчика на приложение так, чтобы получить работающий продукт в срок, а не долгую переписку с исполнителем, который «почти закончил».

Эта статья — практическое руководство для основателей и руководителей, которым нужно заказать мобильное приложение на стороне и не ошибиться с исполнителем. Мы разберём, где искать подрядчика, чем студия отличается от фрилансера, как проверить портфолио прямо в App Store и Google Play, по каким критериям сравнивать кандидатов и какие красные флаги должны насторожить ещё на этапе переговоров.

TL;DR: Правильный выбор начинается с типа задачи: шаблонное решение обходится от 150 000–300 000 ₽ за 3–6 недель, кастомная разработка — от 700 000 ₽ (MVP) или от 2 000 000 ₽ для сложного продукта. Проверьте живые приложения кандидатов в App Store и Google Play, запросите контакты прошлых клиентов и пропишите передачу исходного кода и аккаунтов в договоре.

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

Мобильная разработка отличается от веба сразу несколькими вещами, и это напрямую влияет на выбор исполнителя. Приложение живёт не на вашем сервере, а в двух чужих магазинах — App Store и Google Play — со своими правилами модерации, требованиями к приватности и регулярными изменениями гайдлайнов. Оно работает на сотнях моделей устройств с разными экранами, версиями ОС и мощностью. И, в отличие от сайта, его нельзя «просто обновить» — каждая новая версия проходит проверку магазина, а пользователи обновляются не сразу.

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

Что сделать до начала поиска подрядчика

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

Что именно вы строите. Сформулируйте тип приложения (маркетплейс, сервис-по-подписке, корпоративный инструмент), целевую аудиторию и ключевые пользовательские сценарии — хотя бы на уровне «пользователь заходит → видит каталог → оформляет заказ». Без этого любая смета будет плюс-минус лапоть.

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

Тип продукта	Стоимость	Сроки	Подходит для
Шаблонное/типовое решение	от 150 000–300 000 ₽	3–6 недель	Визитка, маркетплейс на конструкторе, стандартный b2c-каталог
MVP с нуля	от 700 000–1 500 000 ₽	2–4 месяца	Проверка гипотезы, уникальная логика, минимальный рабочий продукт
Сложный продукт	от 2 000 000 ₽	4–12 месяцев	Интеграции с внешними системами, масштаб, высокая нагрузка

Платформы. iOS и Android одновременно — это две отдельные кодовые базы при нативной разработке. Кроссплатформенный подход (Flutter, React Native) позволяет запустить обе платформы из одного кода и сэкономить 30–40% бюджета, сохранив при этом нативный внешний вид. Если ваша аудитория явно смещена в сторону одной платформы — начните с неё.

Где искать подрядчика: студия, фриланс, собственная команда

Прежде чем сравнивать конкретных исполнителей, определитесь с форматом. У каждого — свой баланс цены, скорости и рисков.

• Профильная студия (аутсорс под ключ). Команда с дизайнерами, разработчиками под iOS и Android, тестировщиками и менеджером. Отвечает за результат по договору, ведёт проект от аналитики до публикации и поддержки. Дороже фриланса, но предсказуемее по срокам и качеству — оптимальный вариант для большинства бизнес-проектов.
• Фрилансеры. Дешевле и гибче, но один человек редко закрывает весь цикл: дизайн, две платформы, бэкенд, тестирование и публикацию. Риски по срокам и «пропаданию» исполнителя выше, а поддерживать продукт после релиза часто оказывается некому. Подходит для небольших задач или доработок, а не для запуска продукта с нуля.
• Биржи и маркетплейсы исполнителей. Помогают быстро собрать список кандидатов и почитать отзывы, но не снимают с вас задачу проверки. Рейтинг на площадке — не гарантия компетенций именно в мобильной разработке.
• Собственная команда (инхаус). Оправдана, когда приложение — ядро бизнеса и его развивают годами. Требует найма, управления и постоянной загрузки, поэтому для запуска и проверки гипотез чаще выбирают внешнего подрядчика, а свою команду собирают позже.

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

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

Модели сотрудничества и оплаты

Формат договора определяет, кто несёт риски и насколько гибко можно менять задачу по ходу. Три основные модели:

• Fixed price (фиксированная цена). Подрядчик оценивает объём и называет итоговую стоимость. Подходит, когда требования детально описаны и меняться не будут. Минус — любая правка вне ТЗ обсуждается отдельно, а команда закладывает риск в цену.
• Time & Material (оплата за время). Вы платите за фактически потраченные часы. Гибко, если продукт развивается итерациями и требования уточняются на ходу, но требует вовлечённости заказчика и контроля бюджета.
• Dedicated team (выделенная команда). Подрядчик выделяет специалистов под ваш проект на постоянной основе. Разумно для длинных продуктов, которые развиваются месяцами и годами.

Выбор модели тесно связан с тем, насколько зрелые у вас требования. Если вы ещё проверяете гипотезу — гибкие модели удобнее; если объём зафиксирован — fixed price снижает неопределённость. Подробнее о том, как устроен аутсорс и как в принципе не обжечься при выборе внешней команды, мы разбирали в отдельном материале про аутсорсинг разработки и выбор подрядчика — здесь же сфокусируемся на мобильной специфике.

Как проверить подрядчика: портфолио, сторы, отзывы

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

Проверяйте не только то, что показывают на сайте, а живые приложения в магазинах:

Что проверить	На что смотреть
Приложения в App Store и Google Play	Приложения из портфолио реально опубликованы, открываются и работают, а не «висят» в статусе черновика
Свежесть обновлений	Дата последнего апдейта: живой продукт обновляется регулярно, заброшенный — годами стоит без изменений
Рейтинг и отзывы пользователей	Оценка и характер отзывов, как команда реагирует на жалобы и баги
Стабильность	Приложение не вылетает при первом запуске, корректно ведёт себя на вашем устройстве
Отзывы клиентов	Контакты предыдущих заказчиков, готовность подрядчика их дать
Кейсы с цифрами	Не просто «сделали приложение», а задача, решение и измеримый результат

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

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

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

• Опыт под нужную платформу и подход. Уточните, есть ли у команды проекты под нативную разработку (Kotlin для Android, Swift для iOS) и кроссплатформенную (Flutter, React Native). Выбор влияет на бюджет и производительность, и подрядчик должен уметь честно объяснить, что подходит под вашу задачу, а не продавать один знакомый ему стек.
• Публикация в сторах. Спросите, кто занимается выкладкой в App Store и Google Play, проходил ли подрядчик модерацию и решал ли отказы. Публикация — отдельная компетенция, и её отсутствие всплывает в самый неподходящий момент.
• Дизайн и UX под мобильные платформы. Интерфейс должен соответствовать гайдлайнам iOS и Android, а не быть «натянутым» с сайта. Хороший подрядчик показывает, как он проектирует пользовательские сценарии.
• Тестирование на реальных устройствах. Уточните, как команда проверяет приложение на разных моделях и версиях ОС. Отдельная услуга тестирования и обеспечения качества — признак зрелого процесса, а не экономии на QA.
• Поддержка после релиза. Приложение требует обновлений под новые версии iOS и Android, иначе через год оно перестаёт корректно работать. Заранее договоритесь, что входит в поддержку и сколько она стоит.
• Юридическая чистота: код, права и аккаунты. В договоре должны быть прописаны передача исходного кода, права на результат и NDA. Аккаунты разработчика в сторах оформляйте на свою компанию, а не на подрядчика.
• Коммуникация и прозрачность. Регулярные демо, доступ к таск-трекеру и понятная отчётность важнее красивых обещаний. С командой вам работать месяцами — комфорт общения имеет значение.

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

Сводная таблица критериев оценки подрядчика

Критерий	На что смотреть	Красный флаг
Опыт в мобильной разработке	Проекты под iOS и Android, знание нативного и кроссплатформенного стека (Swift, Kotlin, Flutter)	Только веб-проекты, «заодно делаем мобилку»
Портфолио в сторах	Живые приложения, свежие апдейты, рейтинг ≥ 4.0, ответы на отзывы	Только концепты и макеты, ни одного опубликованного приложения
Публикация и модерация	Команда проходила отклонения App Store, умеет оформлять App Privacy и описание	Публикация «вами самими», команда не понимает гайдлайнов
Тестирование	Ручное и автотестирование, проверка на реальных устройствах, отдельный QA в команде	«Тестируем сами в последний день»
Коммуникация	Регулярные демо, PM или тимлид как единая точка контакта, доступ к таск-трекеру	Ответы через несколько дней, нет понятного канала
Договор и права	Передача исходного кода, NDA, аккаунты сторов на заказчика, поэтапная оплата	Код остаётся у подрядчика, аккаунты на разработчика
Поддержка после релиза	Чёткий SLA, стоимость и состав поддержки прописаны до старта	«Договоримся потом», поддержка не упоминается
Цена и смета	Детальная смета с разбивкой по этапам, обоснование бюджета	Цена без вопросов и ТЗ, «приложение за N ₽ под ключ» вслепую

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

Некоторые сигналы почти всегда предвещают проблемы. Стоит насторожиться, если подрядчик:

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

Чек-лист выбора подрядчика

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

1. Опишите задачу: что за приложение, под какие платформы, ключевые сценарии и примерный бюджет.
2. Определитесь с форматом — студия, фриланс или инхаус — и моделью оплаты.
3. Соберите 3–5 кандидатов по рекомендациям, портфолио и профильному опыту.
4. Проверьте их приложения прямо в App Store и Google Play: свежесть, рейтинг, стабильность.
5. Запросите контакты прошлых клиентов и поговорите с ними.
6. Сравните кандидатов по критериям: платформы, публикация, тестирование, поддержка, права на код.
7. Проверьте договор: сроки, этапы, передача кода и аккаунтов, NDA, условия поддержки.
8. Выберите команду, с которой понятно и комфортно общаться, — вам работать вместе месяцами.

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

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

• Какой стек используете и почему именно он для моего проекта? Ответ должен быть аргументированным, а не «мы работаем только на Flutter». Хорошая команда объяснит плюсы и минусы разных подходов под вашу задачу.
• Кто будет вести мой проект — PM или тимлид? Как организована коммуникация? Уточните, как часто проводятся демо и отчёты, через какой канал вести переписку, кто принимает решения.
• Сколько приложений вы публиковали самостоятельно? Были ли отклонения от App Store и как вы их решали? Публикация — это отдельная компетенция. Опытная студия может вспомнить конкретные кейсы отклонений и объяснить, как они их разрешили.
• Как у вас устроено тестирование? Есть ли выделенный QA? Узнайте, тестируют ли они на реальных устройствах, какие модели используют, покрывают ли регрессионными тестами.
• Что входит в поддержку после релиза и сколько она стоит? Поддержка должна быть прописана до старта, а не «обсудим потом».
• Кому принадлежит исходный код после сдачи проекта? На кого оформлены аккаунты в сторах? Правильный ответ: код и аккаунты — заказчику.
• Можете дать контакты двух-трёх прошлых клиентов? Прозрачная команда ответит сразу.

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

Поддержка приложения после релиза: что важно согласовать заранее

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

До подписания договора согласуйте следующие параметры:

• Гарантийный период. Как правило — 1–3 месяца после релиза, в течение которых студия бесплатно исправляет баги, выявленные в продакшне. Уточните, что именно считается гарантийным случаем, а что — новой задачей.
• Состав технической поддержки. Что включено: исправление крашей, адаптация под новые версии iOS/Android, обновление зависимостей, мониторинг работоспособности? Каждый пункт стоит денег, и его стоит проговорить заранее.
• SLA и время реакции. Насколько быстро команда реагирует на критический баг (приложение не открывается) и на обычный (кнопка не на том месте)? Хорошая практика — разделить обращения по приоритетам с конкретными сроками.
• Стоимость и модель оплаты поддержки. Это может быть абонентская плата, почасовой тариф или пакет часов. Важно понимать это до старта, а не оказаться с неработающим приложением и неожиданным счётом.
• Развитие и новые фичи. Уточните, может ли та же команда взять новый спринт по развитию продукта или поддержка ограничена только hotfix-ами.

Компания, которая уклоняется от разговора о поддержке или говорит «разберёмся по ходу», — сигнал риска. Зрелая студия предложит типовой SLA-договор ещё на этапе пресейла.

Заключение

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

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

Найдём лучшее решение для вас

Частые вопросы (FAQ)

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

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

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

Откройте портфолио студии прямо в App Store и Google Play: живые приложения, свежие обновления, реальные отзывы и рейтинг говорят больше, чем красивые кейсы на сайте. Проверьте, публиковались ли приложения от аккаунта разработчика, попросите контакты предыдущих клиентов и уточните, кто владеет исходным кодом и аккаунтами в сторах.

Что выбрать: студию, фрилансера или собственную команду?

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

Кому должны принадлежать исходный код и аккаунты в App Store и Google Play?

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

По каким рейтингам найти студию для разработки мобильного приложения?

Из основных: Tagline и «Рейтинг Рунета» ежегодно ранжируют российских разработчиков мобильных приложений по портфолио, отзывам и оборотам. Наличие студии в таком рейтинге — полезный первичный фильтр при составлении шорт-листа. После отбора по рейтингу обязательно проверяйте живые приложения кандидатов в App Store и Google Play и запрашивайте контакты прошлых клиентов.

Чем шаблонное мобильное приложение отличается от разработки с нуля?

Шаблонное (типовое) решение собирается из готовых модулей: оно дешевле (от 150 000–300 000 ₽) и быстрее (3–6 недель), но ограничено в настройке. Разработка с нуля даёт полную свободу функционала и дизайна: MVP обходится от 700 000 ₽ за 2–4 месяца, сложный продукт — от 2 000 000 ₽ и полгода и дольше. Шаблон подходит для стандартных сценариев (визитка, каталог); кастом — когда логика уникальна или нужны интеграции.

Что входит в поддержку мобильного приложения после релиза?

Поддержка обычно включает: гарантийный период 1–3 месяца (бесплатное исправление релизных багов), адаптацию под новые версии iOS и Android, обновление зависимостей, мониторинг и реакцию на критические падения. Стоимость и состав нужно согласовать до старта — в виде SLA с разделением по приоритетам и временем реакции.

Какие ключевые вопросы задать подрядчику на первой встрече?

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