Вы решили сменить команду, которая делает ваше приложение. Причины разные: сорванные сроки, рост цены каждой правки, баги после каждого релиза. Но новая команда не может честно оценить работу, пока не поймёт, в каком состоянии проект.
Без проверки вы рискуете купить кота в мешке. Новый подрядчик увидит запутанный код и либо заложит в смету «запас на неизвестное», либо предложит переписать всё с нуля. Оба варианта стоят дорого, а решение принимается вслепую.
Аудит мобильного приложения превращает ощущения («оно тормозит», «разработчики говорят, что всё сложно») в конкретные факты: список проблем, оценка рисков, понятный план работ. Он же защищает вас при передаче проекта: вы фиксируете, что именно получаете и что должен отдать прежний подрядчик.
В статье разберём, когда аудит действительно нужен, что проверяют в коде, как оценивают стабильность и скорость, какие артефакты должны остаться после передачи и сколько всё это стоит. Материал написан для владельцев бизнеса и маркетологов, поэтому без лишней академичности, но с цифрами и чек-листами, которые можно положить на стол своему техспециалисту.
Если вы уже чувствуете, что проект «дышит на ладан», читайте дальше: часть проверок можно сделать самостоятельно за один вечер.
Когда нужен аудит: признаки проблем и смены подрядчика
Аудит не нужен каждому приложению каждый квартал. Но есть ситуации, когда без него не обойтись, и их лучше распознать заранее.
Первая группа признаков связана с поведением команды и бюджетом. Если простая правка, например смена текста на экране оплаты, оценивается в несколько дней, значит, код стал хрупким. Если каждый релиз приносит новые баги в старых местах, это классический симптом накопленного техдолга.
- сроки задач растут, хотя команда та же;
- разработчики не могут объяснить, как устроена часть системы;
- релизы выходят реже, чем раз в месяц, и всегда «с сюрпризами»;
- рейтинг в сторах падает, в отзывах слова «вылетает» и «тормозит»;
- в проекте один «незаменимый» разработчик, который знает всё.
Вторая группа сигналов относится к самой смене подрядчика. Аудит нужен, когда вы переходите к другой команде, привлекаете инвестора, готовитесь к продаже бизнеса или масштабированию. Инвестор при due diligence почти наверняка спросит про состояние кода и права на него.
Не поручайте аудит текущему подрядчику, если вы с ним расстаётесь. Конфликт интересов неизбежен: он оценивает собственную работу. Нужен независимый взгляд.
Отдельно про техдолг мобильного приложения. Это не только «плохой код». Это устаревшие библиотеки, отсутствие тестов, обходные решения, которые «временно» живут уже три года. Он растёт незаметно, а платите вы за него каждой задачей: по опыту, в запущенных проектах до 30-40% времени разработки уходит не на новые функции, а на борьбу со старыми проблемами.
Если узнали свой проект в нескольких пунктах, аудит окупится уже на этапе выбора нового подрядчика.
Что проверяется в коде: архитектура, зависимости, безопасность
Аудит кода приложения состоит из трёх крупных блоков. Каждый отвечает на свой вопрос: можно ли развивать продукт, на чём он стоит и насколько он безопасен.
Архитектура. Смотрят, разделены ли слои: интерфейс, бизнес-логика, работа с данными. Если вся логика лежит в экранах, любое изменение ломает соседние функции. Оценивают размер «божественных» классов (файлы на 3000+ строк), дублирование кода и соблюдение принятых паттернов, например MVVM или Clean Architecture. Отдельно проверяют, как устроено взаимодействие с сервером и офлайн-режим.
Зависимости. Современное приложение состоит из десятков сторонних библиотек. Проверяют:
- версии SDK и библиотек: что устарело и что больше не поддерживается;
- соответствие требованиям Google Play и App Store по целевой версии API (с каждым годом планка растёт, и отставание грозит блокировкой обновлений);
- лицензии: нет ли компонентов, запрещающих коммерческое использование;
- наличие известных уязвимостей (CVE) в используемых пакетах.
Быстрая самопроверка: попросите у подрядчика файл зависимостей (Podfile.lock, build.gradle, pubspec.lock) и отправьте независимому специалисту. Уже по нему видно, насколько проект запущен.
Безопасность. Это самая дорогая зона ошибок. Ищут ключи API и пароли, зашитые прямо в код, хранение токенов в открытом виде, отсутствие шифрования трафика и проверки сертификатов, избыточные разрешения приложения. Сверяются с чек-листом OWASP MASVS, это отраслевой стандарт для мобильной безопасности. Если приложение работает с платежами или персональными данными, проверяют и соответствие 152-ФЗ.
Результат этого блока: карта рисков с приоритетами «критично», «важно», «можно отложить». Именно она показывает, стоит ли развивать текущую кодовую базу или дешевле переписать отдельные модули.
Производительность и стабильность: краши, утечки памяти, время запуска
Код может выглядеть аккуратно, а пользователи всё равно уходят. Поэтому вторая часть аудита опирается на измерения на реальных данных, а не на мнение проверяющего.
Краши и ошибки. Открывают Firebase Crashlytics, Sentry или аналоги, если они подключены. Ориентир по отрасли: доля сессий без сбоев (crash-free sessions) должна быть не ниже 99,5%. Всё, что ниже 99%, уже заметно сказывается на рейтинге. Если мониторинга нет вообще, это отдельная находка: подрядчик работал вслепую.
Утечки памяти и расход ресурсов. Их ищут профилировщиками: Xcode Instruments, Android Profiler, LeakCanary. Типичные симптомы: приложение «пухнет» после 10-15 минут работы, телефон греется, батарея садится быстрее обычного. Проверяют также фоновые процессы и частоту сетевых запросов.
Время запуска. Пользователь ждёт недолго. Ориентиры:
- холодный старт до 2 секунд на среднем устройстве считается хорошим результатом;
- 3-5 секунд уже заметно увеличивают долю отказов;
- дольше 5 секунд критично, особенно для бюджетных Android-устройств.
Тестируйте не на флагмане разработчика. Возьмите телефон трёхлетней давности с 3-4 ГБ памяти: именно такими пользуется значительная часть аудитории.
Дополнительно проверяют поведение при плохой сети, размер установочного файла, отрисовку списков и анимаций (кадры в секунду), а также работу на разных версиях ОС. Итогом становится таблица метрик «сейчас и целевое значение». С ней удобно ставить задачи новой команде и потом оценивать, улучшилось ли что-то на самом деле.
Если приложение связано с внешними сервисами, отдельно смотрят устойчивость интеграций: таймауты, повторные запросы, обработку ошибок сервера. Именно здесь часто прячутся редкие, но дорогие сбои.
Документация, тесты и CI/CD: что должно остаться после передачи проекта
Хорошая передача проекта разработчику это не архив с исходниками на флешке. Это набор артефактов, с которыми новая команда стартует за дни, а не за месяцы. Проверьте их наличие в ходе аудита, а лучше пропишите в договоре.
Доступы и права. Они важнее всего. Аккаунты App Store Connect и Google Play Console должны быть оформлены на вашу компанию, а не на личный аккаунт подрядчика. То же касается репозитория, серверов, доменов, push-сервисов, аналитики и сертификатов подписи. Потеряв ключ подписи Android, вы не сможете обновлять приложение под прежним именем.
Тесты. Смотрят покрытие модульными тестами критичной логики (оплата, авторизация, расчёты) и наличие автоматических UI-тестов основных сценариев. Нулевое покрытие означает, что любое изменение новая команда будет проверять руками, а это рост стоимости каждого релиза.
CI/CD. Сборка и выкладка должны происходить автоматически, а не на ноутбуке одного разработчика. Проверьте, что есть конфигурация пайплайна (GitHub Actions, GitLab CI, Bitrise), автоматический запуск тестов и воспроизводимая сборка.
Минимальный пакет передачи:
- исходный код со всей историей коммитов;
- описание архитектуры и схема взаимодействия с сервером;
- инструкция по локальному запуску и сборке релиза;
- документация API и список внешних сервисов;
- все доступы, ключи и сертификаты на владельца бизнеса;
- список известных багов и незавершённых задач.
Проведите «тестовое развёртывание»: попросите нового специалиста собрать приложение с нуля только по документации. Всё, на чём он застрянет, и есть пробелы передачи.
Ключевые выводы
- Аудит должен делать независимая команда, а не уходящий подрядчик.
- Критичны три зоны: архитектура и зависимости, безопасность, измеримая стабильность (crash-free от 99,5%).
- Доступы к сторам, репозиторию и ключам подписи должны принадлежать вашей компании.
- Без тестов и CI/CD каждый релиз дорожает, а новая команда работает медленнее.
Стоимость аудита, сроки и как заказать его у внешней команды
Цена зависит от размера приложения, числа платформ и глубины проверки. Ориентиры для рынка 2026 года ниже, точная смета всегда зависит от проекта.
- Экспресс-аудит (2-4 дня): обзор архитектуры, зависимостей, базовая проверка безопасности и метрик. Подходит для небольшого приложения, 40-100 тыс. руб.
- Стандартный аудит (1-2 недели): полный разбор кода, профилирование, анализ CI/CD и документации, план работ. Обычно 120-300 тыс. руб.
- Расширенный аудит (3-5 недель): сложные платформы с несколькими клиентами и бэкендом, тестирование на проникновение, оценка затрат на рефакторинг. От 350 тыс. руб.
Для сравнения: ошибка в выборе подрядчика или решение переписать приложение, которое можно было спасти, обходится в миллионы. Аудит составляет, как правило, 2-5% от суммы последующей разработки.
Как заказать. Подготовьте доступ к репозиторию (на чтение), консолям сторов и системе мониторинга, а также описание бизнес-целей. Чем яснее цель, тем полезнее отчёт: «подготовиться к росту трафика в 5 раз» требует иных проверок, чем «выбрать, кому отдать поддержку».
Подпишите NDA до передачи кода и убедитесь, что доступы выдаются временные и только на чтение.
Хороший отчёт содержит краткое резюме для руководителя, список находок по приоритетам, оценку трудозатрат на исправление и рекомендацию: развивать, частично переписать или заменить. Дальше возможны разные сценарии: от поддержки существующего продукта в рамках техподдержки приложений до пересборки ядра как нового MVP. Если нужно решить, какой путь выгоднее бизнесу, поможет консалтинг для стартапов.
Заключение
Смена подрядчика это момент, когда можно или закрепить хаос, или навести порядок. Аудит даёт объективную картину: где проект крепок, где скрыт техдолг, какие риски по безопасности нужно закрыть немедленно, а что подождёт.
Практический порядок действий простой. Сначала убедитесь, что все доступы принадлежат вам. Затем закажите независимую проверку кода, стабильности и процессов сборки. После этого составьте перечень артефактов, которые подрядчик обязан передать, и только тогда выбирайте новую команду, опираясь на отчёт, а не на обещания в презентации.
Так вы платите за реальные работы, а не за «запас на неизвестное», и получаете предсказуемый старт. Даже если выяснится, что приложение придётся серьёзно переделывать, вы будете знать это заранее и сможете спланировать бюджет и сроки без неприятных сюрпризов.