Что должно быть в MVP приложения, а что подождёт

В первую версию входит один сценарий целиком плюс то, без чего приложение не пройдёт проверку в App Store и Google Play. По моему опыту MVP мобильного приложения это 8-12 экранов, 8-10 недель и от 350 000 ₽ - нижняя граница вилки, потому что весь верх вилки как раз и состоит из отложенного.

Дальше - что относится к «одному сценарию целиком», что обязательно даже в самом маленьком приложении, и какие вещи нельзя переносить во второй релиз, потому что переделка выйдет дороже, чем сделать сразу.

Разработка мобильных приложенийот 350 000 до 1 200 000 ₽сроки: 8-16 недель до релиза в сторах

Главная ошибка: урезать всё вместо того, чтобы вырезать лишнее

Заказчик приносит список из сорока функций и просит сделать «пока попроще». В итоге появляется приложение, где регистрация есть, но без восстановления пароля. Каталог есть, но без поиска. Заказ оформляется, но статус не виден. Пользователь заходит, упирается в первую же обрубленную ветку и удаляет приложение.

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

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

Что входит в MVP мобильного приложения

Ядро - это цепочка от входа до результата, без разрывов:

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

Плюс к этому - обвязка, без которой сторы не пропустят сборку. Её проще смотреть списком.

Без чего приложение не пройдёт проверку

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

Политика конфиденциальности. Нужна ссылка, доступная и в сторе, и внутри приложения. Страница должна открываться без авторизации и реально описывать, какие данные собираются.

Удаление аккаунта. Если в приложении есть регистрация, Apple по гайдлайну 5.1.1(v) требует возможность удалить аккаунт из самого приложения. Не письмом в поддержку, а кнопкой. Приложения без неё отклоняют молча и стабильно.

Демо-доступ для проверяющего. Логин и пароль тестового пользователя в поле App Review Information, а если вход по SMS - постоянный тестовый номер с фиксированным кодом. Проверяющий не будет регистрироваться по вашей боевой схеме и не станет ждать код на чужой телефон.

Корректно заполненная App Privacy. Декларация о сборе данных должна совпадать с тем, что приложение делает на самом деле. Расхождение обнаруживается автоматикой Apple и возвращается с формулировкой про недостоверные метаданные.

Чеклист

Что входит в первую версию, а что нет

Разбивка для гибридного приложения на iOS и Android объёмом 8-12 экранов.

22 проверок 9 критично 3 важно 10 можно потом

01 Без этого не будет релиза

• критично Политика конфиденциальности: ссылка в сторе и экран внутри приложения чинить до запуска
• критично Удаление аккаунта из приложения, если есть регистрация чинить до запуска
• критично Демо-доступ для проверяющего: логин, пароль или тестовый номер с фиксированным кодом чинить до запуска
• критично App Privacy и разрешения в Info.plist совпадают с реальным поведением чинить до запуска
• критично Иконка, экран запуска, скриншоты под все требуемые размеры чинить до запуска
• критично Обработка отсутствия сети: экран вместо белого пятна чинить до запуска

02 Ядро сценария

• критично Авторизация и модель пользователя с запасом на роли чинить до запуска
• критично Список и карточка основного объекта чинить до запуска
• критично Целевое действие: оплата, запись, заявка чинить до запуска
• важно История действий: заказы, билеты, записи в первый месяц
• важно Push о статусе целевого действия в первый месяц
• важно Канал обратной связи внутри приложения в первый месяц

03 Можно во второй релиз

• можно потом Тёмная тема когда дойдут руки
• можно потом Планшетная вёрстка когда дойдут руки
• можно потом Вторая роль пользователя и её интерфейс когда дойдут руки
• можно потом Фильтры и сортировки сверх базового поиска когда дойдут руки
• можно потом Офлайн-режим с локальной синхронизацией когда дойдут руки

04 Часто просят, но обычно не нужно

• можно потом Лента и подписки на других пользователей когда дойдут руки
• можно потом Чат внутри приложения когда дойдут руки
• можно потом Сложная аналитика поведения с тепловыми картами экранов когда дойдут руки
• можно потом Геймификация: уровни, достижения, рейтинги когда дойдут руки
• можно потом Авторизация через пять социальных сетей сразу когда дойдут руки

Что откладывают и не жалеют

Соцсети внутри продукта. Подписки, лента, лайки. Это отдельный продукт по объёму работы, и он мёртв без критической массы пользователей, которой у первой версии по определению нет.

Чат. Выглядит как «просто переписка», а на деле это сокеты, доставка, прочитанность, вложения, модерация и жалобы. В первой версии его закрывает кнопка «написать в Telegram» или обычная почта.

Сложная продуктовая аналитика. Тепловые карты экранов и запись сессий полезны, когда есть трафик. На двухстах пользователях больше скажут пять правильно названных событий.

Тёмная тема. Дублирует всю палитру и удваивает визуальный QA. Отложенная тёмная тема не стоила мне ни одного плохого отзыва.

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

Вторая роль. Каждая роль это отдельный набор экранов, прав и состояний. На платформе событий ролей в итоге стало четыре - фотограф, контролёр билетов, SMM и админ, - но появлялись они по одной, а не разом.

Что откладывать нельзя

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

Модель пользователя и авторизация. Если завтра появятся роли, а сегодня пользователь это просто телефон и имя, придётся мигрировать всех. Заложить поле роли и разделение прав на старте стоит день. Переделать потом - неделю плюс миграция боевой базы.

Структура данных. Переименовать сущность в схеме на второй неделе бесплатно. На четвёртом месяце это миграции, обновление контрактов API и версия приложения, которая ещё живёт на телефонах у людей.

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

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

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

Как понять, что первая версия взлетела

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

Метрика	Что смотреть	Ориентир
Retention 1 день	Вернулись назавтра после установки	ниже 20% - сценарий непонятен
Retention 7 дней	Вернулись через неделю	ниже 8% - продукт не нужен регулярно
Доля завершённых сценариев	Дошли от входа до целевого действия	ниже 30% - проблема в пути, а не в идее
Крэши	Сессий без падений	ниже 99% - чинить до любых новых функций

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

Сроки и деньги

Первая версия на 8-12 экранов занимает 8-10 недель и стоит от 350 000 ₽. Верх вилки, до 1 200 000 ₽, набирается из ролей, интеграций, офлайна и админки - того самого, что в MVP не входит.

Гибридный подход здесь помогает: один код на Capacitor даёт iOS, Android и веб сразу, а нативные плагины на Swift и Kotlin дописываются точечно там, где веб-слоя не хватает. На платформе событий это сэкономило больше 10 000 $ против двух нативных команд. Граница у подхода есть, и я называю её сам: игры, тяжёлая графика и постоянная фоновая работа с железом делаются нативно.

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