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

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

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

Переплата появляется не потому, что новая команда жадная, а потому что она не может оценить риск. Когда приходит проект без документации, без тестов и с историей коммитов вида «fix», «fix2», «final fix», единственный честный ответ — «мы не знаем, что там внутри». Подрядчик закладывает запас на неизвестность, и этот запас иногда равен половине сметы.

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

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

Запрашивайте всё письмом со списком пунктов и просите подтвердить каждый — устные «конечно передадим» не работают. Минимальный набор выглядит так.

Аккаунты дистрибуции: Apple Developer Program (роль Account Holder, а не просто Admin), Google Play Console с правами владельца, доступ к App Store Connect и к почте, на которую они зарегистрированы. Сюда же — ключ подписи Android (keystore и пароли к нему) или подтверждение, что подключён Play App Signing, сертификаты и provisioning-профили iOS.

Код и инфраструктура: приватный репозиторий со всеми ветками и тегами релизов, доступ к CI/CD, панель хостинга, SSH-ключи к серверам, дамп базы данных, конфигурация окружений dev/stage/prod. Отдельно — ключи и токены платёжных систем, пуш-сервисов, карт, аналитики, SMS-шлюза.

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

Приёмка делится на два этапа. Технический аудит занимает от 20 до 50 часов и стоит примерно 80–150 тысяч рублей: команда разворачивает проект локально, собирает билд, читает архитектуру, проверяет зависимости на устаревание и уязвимости, смотрит логи ошибок и пишет отчёт с оценкой рисков. Второй этап — стабилизация: закрыть критичные дыры, настроить сборку и выпустить первый релиз своими силами, ещё 100–300 тысяч рублей в зависимости от объёма.

Переписывать с нуля имеет смысл в трёх случаях. Первый — приложение написано на технологии, которую больше не поддерживают, например на давно заброшенном гибридном фреймворке. Второй — нет исходников, есть только собранные файлы в сторах. Третий — стоимость доведения кода до рабочего состояния превышает 60–70 % стоимости новой разработки; посчитать это можно только после аудита. Ориентиры по бюджетам мы разбирали в материале «Сколько стоит разработка мобильного приложения для Android и iOS», там же — вилки по типам проектов.

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

Мы разбиваем аудит на пять проверок, каждая даёт понятный сигнал. Первая — «собирается ли». Новый разработчик приложения получает репозиторий и пробует за один рабочий день поднять проект и выпустить debug-билд. Если получилось за 4–6 часов — код в порядке.

Вторая проверка — зависимости. Смотрим версии SDK, целевую версию Android API и минимальную iOS, библиотеки с известными уязвимостями и брошенные пакеты. Google и Apple регулярно поднимают требования к target SDK, и приложение, которое два года не обновляли, может просто не приниматься в стор до модернизации.

Третья — архитектура и связность. Читаем три самых больших файла в проекте: если экран оформления заказа занимает 2000 строк и в нём же лежат запросы к API, парсинг и логика скидок, любая доработка будет ломать соседнее.

Четвёртая — backend: есть ли отдельные окружения, как хранятся секреты, не лежат ли пароли в репозитории открытым текстом.

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

По итогам получается отчёт на 10–15 страниц с тремя списками: что чинить немедленно, что можно вытерпеть полгода и что переписывать при следующем крупном релизе. Этот документ и есть основание для сметы — он же защищает вас от разговора «мы тут ещё нашли, доплатите».

Ситуация неприятная, но решаемая. Аккаунт Apple Developer восстанавливается через обращение в поддержку с документами юрлица, если разработчик приложений регистрировал его на вашу компанию; если на себя как на физлицо — придётся создавать новый аккаунт организации, получать D-U-N-S номер и публиковать приложение заново под новым идентификатором. Порядок регистрации и оплаты мы описывали в статье про аккаунт Apple Developer.

С Google Play чуть проще: если подключено Play App Signing, потеря keystore не критична — ключ загрузки можно перевыпустить через консоль. Если подписывали вручную и keystore утерян, обновить существующее приложение невозможно, нужен новый пакет с другим applicationId, а старые пользователи не перенесутся автоматически.

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

К нам пришёл заказчик из сферы услуг, у которого за полтора года сменились две команды. Первая сделала нативные приложения для iOS и Android и пропала, вторая начала переписывать всё на кроссплатформу, дошла до 60 % и разошлась с клиентом по деньгам. На руках были два репозитория, ни один из которых не собирался, и живое приложение в сторах, обновлять которое никто не мог.

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

Решение — вернуться к нативной ветке, обновить SDK, перевыпустить сертификаты и выпустить релиз за три недели вместо запланированных трёх месяцев переписывания. Итоговая экономия составила около 1,4 миллиона рублей. Кроссплатформенный код не выбросили: часть бизнес-логики и экранов перенесли в бэклог как задел на будущее.

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

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

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

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

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

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

Правило третье: релиз выпускается через вашу инфраструктуру. Если сборка идёт на CI, привязанном к вашему аккаунту, а не на чьём-то ноутбуке, смена команды перестаёт быть катастрофой.

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

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

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

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

Можно ли дорабатывать приложение, если исходников нет вообще?

Нет. Из опубликованного пакета можно вытащить ресурсы и примерно понять структуру, но восстановить читаемый исходный код невозможно, а декомпиляция чужого продукта ещё и юридически сомнительна. Единственный рабочий путь — написать приложение заново, сохранив дизайн и логику, и опубликовать обновление через тот же аккаунт в сторе, чтобы не потерять пользователей и отзывы. Бюджет такой пересборки обычно составляет 60–100 % стоимости первоначальной разработки мобильного приложения.

Что делать, если бывший разработчик приложения отказывается отдавать доступы?

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

Сколько стоит аудит чужого кода перед доработкой?

От 80 до 150 тысяч рублей за 20–50 часов работы команды из мобильного разработчика, бэкендера и тестировщика. В результат входит запуск проекта на локальном окружении, сборка тестового билда, проверка зависимостей и уязвимостей, оценка архитектуры и схемы базы данных, а также отчёт с разделением проблем на критичные, средние и отложенные. Этот отчёт превращается в смету на доработку и служит защитой от неожиданных доплат в середине проекта.

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

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