Что делать, если разработчик пропал или отказался от проекта?
Первым делом соберите доступы: код, аккаунты App Store и Google Play, сервер, домен и все подключённые сервисы. Пока доступов нет, любая оценка доработки будет гаданием.
Ситуации бывают разные. Фрилансер перестал отвечать на середине проекта. Студия закрылась или подняла цену в несколько раз. Штатный разработчик уволился, и никто не знает, как собрать новую версию. Приложение работает, но каждое изменение ломает что-то ещё, и подрядчик называет всё новые сроки.
Во всех этих случаях порядок одинаковый. Сначала контроль над продуктом, потом диагностика, потом план. Я не начинаю исправлять код, пока не вижу, что именно у вас есть и в каком оно состоянии.
Какие доступы нужно забрать у прежнего разработчика?
Нужно всё, без чего нельзя собрать, опубликовать и обслуживать приложение. Если чего-то не хватает, это нужно выяснить в первую очередь, пока с прежним подрядчиком ещё есть связь.
| Что забрать | Зачем | Что будет, если нет |
|---|---|---|
| Репозиторий с кодом приложения и бэкенда | Вносить изменения и собирать новые версии | Придётся писать заново |
| Аккаунт App Store Connect | Публиковать обновления для iOS | Новое приложение, отзывы и позиции с нуля |
| Аккаунт Google Play Console и ключи подписи | Публиковать обновления для Android | Сложная процедура восстановления или новое приложение |
| Сервер, база данных, домен | Работа бэкенда и данные пользователей | Риск потерять данные и остановить сервис |
| Сторонние сервисы: Firebase, RevenueCat, аналитика, AI API | Пуши, оплаты, статистика, AI-функции | Функции перестанут работать при смене ключей |
Самая болезненная ситуация — когда аккаунт разработчика в сторе оформлен на подрядчика, а не на вас. Тогда фактически распоряжается приложением он. Перенос приложения между аккаунтами в сторах возможен, но для этого нужно участие владельца текущего аккаунта. Поэтому у меня все аккаунты, код, хостинг и домен оформлены на заказчика с первого дня.
Как запросить доступы, если отношения испорчены
Лучше всего — спокойно и списком. Напишите прежнему разработчику, что проект переходит на поддержку, и перечислите, что нужно передать: репозиторий, доступы к аккаунтам, ключи подписи Android-приложения, пароли от сервера и сервисов. Если в договоре есть пункт о передаче прав на код, сошлитесь на него. Чем конкретнее список, тем меньше поводов затягивать.
Если разработчик не отвечает совсем, часть доступов можно восстановить через сами сервисы, если они оформлены на вашу почту или компанию. С тем, что оформлено на подрядчика, сложнее, и здесь созвон со мной поможет понять, что восстановимо, а что проще сделать заново.
Опишите задачу в паре строк — отвечу в Telegram, назову цену и сроки по этапам. ТЗ не нужно.
Как проходит аудит чужого проекта?
Аудит отвечает на три вопроса: собирается ли проект, насколько он устарел и где в нём главные риски. По итогам вы получаете понятный список проблем и план с ценами.
Что я проверяю:
- Сборка. Можно ли собрать приложение из репозитория с нуля и опубликовать новую версию. Иногда это самая долгая часть: забытые ключи, локальные правки, которых нет в репозитории, устаревшие инструменты.
- Версии и зависимости. На какой версии React Native, Flutter или нативных SDK написано приложение, насколько они отстали от требований сторов.
- Архитектура. Есть ли в коде понятная структура или логика размазана по экранам. Насколько сложно будет добавлять новые функции.
- Оплата и данные. Как проверяются покупки и подписки, где хранятся данные пользователей, есть ли резервные копии.
- Стабильность. Есть ли мониторинг ошибок, какие краши уже случаются у пользователей, где приложение тормозит.
- Безопасность. Не лежат ли ключи от сервисов прямо в коде приложения, закрыт ли доступ к базе данных.
Итог аудита — короткий документ на несколько страниц: что сломано, что опасно, что устарело, и сколько стоит каждое исправление. Дальше вы сами решаете, что делать и в каком порядке.
Во время аудита я сразу подключаю мониторинг ошибок, если его не было, — Sentry или Firebase. Уже через несколько дней становится видно, какие краши реально происходят у пользователей и на каких устройствах. Это честнее любых предположений о том, что сломано.
Дорабатывать или переписывать с нуля?
Дорабатывать, если проект собирается, архитектура хотя бы понятна и основные функции работают. Переписывать стоит, когда исправление каждой ошибки порождает новые, а стоимость доработки приближается к стоимости новой версии.
Признаки, что проект стоит дорабатывать:
- приложение собирается и публикуется, пусть и с усилием;
- проблемы локальные: отдельные экраны, интеграции, производительность;
- стек стандартный и живой — React Native, Swift, Kotlin, Node.js;
- у приложения есть пользователи и отзывы, которые жалко терять.
Признаки, что лучше переписать часть или всё:
- проект на заброшенном фреймворке, который не обновить под требования сторов;
- нет исходного кода, только опубликованная сборка;
- логика оплаты и данных настолько запутана, что её надёжнее сделать заново;
- планируется большой объём новых функций, а текущая основа их не выдержит.
Чаще всего разумен промежуточный вариант: оставить то, что работает, а проблемные части переписать постепенно, этап за этапом. При этом аккаунт в сторе, отзывы, позиции в поиске и пользователи сохраняются — новая версия выходит как обновление существующего приложения.
Важно не принимать это решение на эмоциях. После плохого опыта с подрядчиком часто хочется выбросить всё и начать заново. Но переписывание с нуля — это снова недели разработки, новые ошибки и риск потерять то, что уже работало. Решение принимаю вместе с вами по результатам аудита, с цифрами: сколько стоит доработка, сколько стоит новая версия и что вы получаете в каждом случае.
Если решаем переписывать, я делаю это на React Native — одна кодовая база под iOS, Android и Huawei. Это почти вдвое дешевле двух нативных приложений, а стек стандартный, так что следующий разработчик, если понадобится, разберётся в нём без меня. Ориентиры по бюджету новой версии — в статье сколько стоит мобильное приложение.
Сколько стоит доработка чужого проекта?
Доработка чужого проекта оценивается индивидуально: цена зависит от состояния кода, который я ещё не видел. Точную сумму называю после аудита и фиксирую в договоре.
На оценку влияют:
- есть ли полный доступ к коду и аккаунтам или часть придётся восстанавливать;
- сколько лет проект не обновлялся и насколько отстали зависимости;
- что нужно в итоге: только починить и выпустить обновление или продолжить развитие;
- есть ли бэкенд и в каком он состоянии.
Работа, как и при разработке с нуля, делится на этапы. Первый этап обычно — привести проект в рабочее состояние: собрать, обновить, опубликовать версию без критичных ошибок. После него у вас уже стабильное приложение и понятная база для следующих шагов. Оплата по этапам, без полной предоплаты, акт после каждого этапа. Подробно о гарантиях — на странице о процессе.
Что подготовить к созвону по чужому проекту?
Подготовьте то, что есть на руках: доступы, ссылки на приложение в сторах и список проблем. Даже если доступов пока нет, созвон поможет понять, что и у кого запросить.
- Ссылки на приложение в App Store, Google Play и других сторах, если оно опубликовано.
- Доступ к репозиторию или хотя бы понимание, где лежит код.
- Список аккаунтов — на кого оформлены стор, сервер, домен, платёжные сервисы.
- Что не работает. Ошибки, жалобы пользователей, отказы на ревью, письма от сторов.
- Что вы хотите дальше. Просто стабилизировать приложение или развивать его: новые функции, подписки, выход в RuStore и AppGallery.
- Переписка с прежним разработчиком, если там есть договорённости и описание архитектуры.
Типичная ошибка на этом шаге — пытаться сначала «дописать ТЗ» по старому проекту. Этого не нужно: всё, что нужно для оценки, я увижу в коде и на созвоне.
Вторая типичная ошибка — продолжать выпускать срочные правки у прежнего подрядчика параллельно с аудитом. Код меняется в двух местах, и через неделю уже непонятно, какая версия актуальная. На время передачи лучше заморозить изменения, кроме действительно критичных.
Как не попасть в ту же ситуацию снова?
Держите у себя код, аккаунты и доступы, получайте регулярные демо и работайте по договору с передачей прав на код. Тогда уход любого подрядчика — неприятность, но не катастрофа.
Так я работаю по умолчанию: аккаунты App Store и Google Play, хостинг и домен оформлены на вас с первого дня, у вас есть доступ к репозиторию, каждую неделю — демо и тестовые сборки на ваш телефон. От меня можно уйти после любого этапа, стек стандартный. Как это выглядело в других проектах, можно посмотреть в кейсах.
Если у вас приложение после другого разработчика и непонятно, что с ним делать, опишите ситуацию в форме заявки или напишите в Telegram. Оценка бесплатная: после созвона на 20–30 минут скажу, с чего начать и во что это обойдётся.