Аутсорс мобильной разработки: на что смотреть до старта

«Аутсорс мобильная разработка» — запрос, за которым обычно стоит не абстрактный интерес, а конкретная боль: своей команды разработчиков нет, а приложение нужно. Для бизнеса это нормальная модель — держать штатную мобильную команду ради одного приложения дорого и часто бессмысленно. Вопрос не «отдавать или нет», а «как выбрать команду так, чтобы через год не жалеть».

Первый вопрос: один код или два

Есть два пути сделать приложение для iOS и Android: писать нативно на Swift и Kotlin раздельно, или писать один код на кросс-платформенном фреймворке вроде Flutter, который собирается в оба магазина. Нативная разработка почти всегда означает две команды, два бэклога багов и вдвое больше времени на любую новую функцию. Мы работаем на Flutter именно потому, что для подавляющего большинства бизнес-приложений — каталог, заказы, личный кабинет, интеграция с оплатой — разница в производительности между нативным кодом и Flutter незаметна пользователю, а разница в стоимости поддержки заметна очень сильно.

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

Второй вопрос: кто отвечает за магазины

Написать код — это меньшая часть истории приложения. Есть ещё карточка в App Store и Google Play, скриншоты под требования каждой площадки, тексты для листинга, и сама процедура ревью — у Apple она может занять несколько итераций, если что-то не устраивает модератора. Команда, которая отдаёт вам только собранный файл и говорит «дальше сами», перекладывает на бизнес работу, которую он на аутсорс и отдавал. Мы берём весь путь целиком: от магазинных карточек до прохождения ревью, включая повторные попытки, если первая заявка возвращается с замечаниями.

Третий вопрос: что будет с существующим приложением

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

Четвёртый вопрос: как устроены подписки и покупки внутри приложения

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

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

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

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

Как выглядит разница на практике

Вопрос на созвоне	Ответ, который стоит насторожить	Ответ, которого стоит ожидать
«Один код для iOS и Android?»	«Сделаем нативно, надёжнее» без объяснения зачем	Прямой ответ про Flutter или обоснование, почему нативно нужно именно вам
«Кто публикует в App Store?»	«Пришлём вам файл, публикуете сами»	Команда ведёт публикацию и ревью до одобрения
«У нас уже есть приложение, беспилотное»	Сразу предложение переписать с нуля	Предложение начать с аудита кода

Что мы строили сами

Мы не только берём приложения на аутсорс — часть наших собственных продуктов тоже мобильные. eSIM-бренд Simtegre прошёл через магазины Apple и Google так же, как проходит любое клиентское приложение: с карточками, скриншотами и ревью. Это не для галочки — когда команда сама живёт с последствиями своих архитектурных решений в собственном продукте, она реже предлагает клиенту то, что удобно написать, но неудобно потом поддерживать.

Правило, которым мы пользуемся

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

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