MVP в разработке мобильного приложения: что это, что входит и когда нужен

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

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

MVP (minimum viable product, минимально жизнеспособный продукт) — первая версия продукта, которая решает одну главную задачу пользователя и помогает проверить идею на настоящих людях. Сам термин приписывают Фрэнку Робинсону из компании SyncDev: там пишут, что впервые использовали его в 2001 году. Широко известным его сделал Эрик Рис, автор книги The Lean Startup («Бизнес с нуля»). В блоге в 2009 году он определил MVP как версию нового продукта, которая позволяет команде собрать максимум проверенных знаний о клиентах с минимальными усилиями.

Главное слово здесь «знания», а не «минимум». Рис в том же тексте предупреждает, что MVP, несмотря на название, вовсе не про создание минимальных продуктов. Мы понимаем это так: первую версию делают, чтобы быстрее узнать, нужен ли продукт людям и как они им пользуются. Если первая версия ничего не позволяет измерить, это просто маленькое приложение.

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

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

Если совсем коротко, на вопрос «MVP продукта что это» ответ такой: самая маленькая версия, которой уже можно пользоваться по-настоящему и по которой видно, стоит ли идти дальше.

Эти три слова часто путают, хотя они отвечают на разные вопросы и живут в разных местах.

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

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

Обычно в MVP входит:

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

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

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

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

В Google Play не допускают приложения с ограниченной функциональностью и контентом, а также те, что падают или зависают. RuStore в требованиях к приложениям запрещает приложения без реальной функциональности (заглушки, placeholder-контент) и выдавать мобильный сайт за приложение без дополнительной функциональности. Демо-версии там допускаются, если базовая функциональность работает.

У Google Play есть ещё и порог для новичков. Личные аккаунты разработчиков, созданные после 13 ноября 2023 года, перед выходом в рабочую версию должны провести закрытое тестирование: не меньше 12 тестировщиков, которые участвуют в нём минимум 14 дней подряд. Это правило Google, и его стоит заложить в план запуска с самого начала.

Выходит, MVP в разработке мобильного приложения должен быть маленьким, но законченным. Ранние версии для своих лучше раздавать через тестовые каналы сторов, а в публичный каталог выпускать то, за что не стыдно перед первым случайным пользователем.

Этапы разработки мобильных приложений у MVP те же, что у большого проекта, просто каждый короче и уже. У нас они выглядят так.

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

Здесь же появляется ТЗ. Хорошее ТЗ на разработку мобильного приложения для MVP короткое: гипотеза, которую проверяем, главный сценарий по шагам, платформы, что не делаем в первой версии и по каким цифрам поймём результат. Список «всех функций на будущее» туда лучше не включать, иначе он незаметно станет обязательным.

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

Мы пишем на Flutter и из одной кодовой базы собираем приложение для iOS, iPadOS, macOS и Android. Для MVP это удобно: можно проверить идею сразу на обеих мобильных аудиториях, обычно не удваивая работу. Так сделан наш планировщик Just Plan, он работает на iPhone, Android и Mac. Серверную часть делаем на Java / Spring Boot и PostgreSQL.

Проверяем ошибки и удобство, готовим описания, скриншоты и проходим проверку сторов. Подробно о том, как устроена публикация в RuStore, App Store и Google Play, расскажем в отдельной статье.

Смотрим на цифры, которые договорились считать, и читаем отзывы. В подходе Риса главная работа стартапа выглядит как цикл: превратить идею в продукт, измерить реакцию клиентов и понять, продолжать или менять курс. Любой из двух исходов нормален для MVP: ты узнал, куда вкладывать деньги, до того как вложил их все.

Нам кажется, что проверять спрос рано стоит хотя бы из-за статистики закрытий. CB Insights в отчёте за март 2026 года изучили 431 венчурный стартап, закрывшийся с 2023 года, и установили причины у 385. У 43% из них среди причин есть слабое попадание продукта в рынок (причин у одного стартапа могло быть несколько). Кончившиеся деньги авторы отчёта называют почти всегда последней, а не корневой причиной. Отчёт не про мобильные приложения, но вывод для любого нового продукта похожий.

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

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

Если же приложение у тебя уже есть, MVP тоже не нужен: следующий шаг — доработка готового. Мы берём существующее приложение и развиваем его: новые функции, обновления, поддержка. А если приложение готово, но до сторов так и не дошло, можно заказать только публикацию.

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

Сколько стоит и сколько длится разработка MVP?
Зависит от главного сценария, платформ и серверной части, поэтому типовой цены и срока у нас нет. После брифа и созвона мы оцениваем работу и предлагаем план.

Можно ли выпустить MVP только под одну платформу?
Можно. Но на Flutter приложение для iOS и Android собирается из одного кода, поэтому вторая платформа обычно не удваивает работу.

Сколько времени придётся уделять проекту?
Минимум: поставить требования и согласовать дизайн. Остальное берёт на себя команда.

Что делать после MVP?
Сравнить цифры с тем, что договорились считать до запуска, и решить: развивать продукт дальше, менять его или остановиться.

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