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

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

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

Что такое MVP приложения на деле

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

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

Отсюда понятно, почему «всё, что умеет сайт, только хуже» — не MVP. Такая версия пытается повторить продукт целиком, и ни один сценарий в ней не доведён до конца. Пользователь упирается в недоделанный экран и уходит, а вы так и не узнаёте, что его остановило: сама идея или сломанная кнопка.

Какой вопрос должна закрыть первая версия

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

  • Люди пользуются продуктом регулярно и в движении, а не раз в квартал за столом.
  • Через продукт идут деньги: оплата, депозит, выплаты исполнителям.
  • Продукту нужны пуши, камера, геолокация — то, чего браузер не умеет.

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

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

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

Мобильное приложение или сайт: когда MVP лучше собрать в браузере

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

  • Продукт открывают раз в месяц. С этим сайт справится лучше и дешевле.
  • Идея ещё не проверена ни на ком, кроме основателя.
  • Приложение нужно «чтобы было», а сценарий никто не может назвать.
  • Нужны игры, AR или тяжёлая графика. Это не наш профиль, и такие проекты мы не берём.

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

Если сценарий пока непонятен, первую версию лучше собрать в браузере. Веб-версия с одним сквозным сценарием, от заявки до результата, стоит от 600 000 ₽ и делается за те же восемь недель. Она дешевле, ей не нужно проходить проверку в двух магазинах, и она быстрее попадает к людям. Из чего складывается цена браузерной версии, мы разбирали в статье сколько стоит разработка веб-приложения.

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

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

В первый релиз мы закладываем вот что:

  • Один сценарий, который работает от начала до конца на iOS и Android.
  • Аккаунты, вход и состояния вокруг них: протухшая сессия, блокировка, восстановление пароля.
  • Бэкенд, который нужен этому сценарию, или интеграция с тем, что у вас уже есть.
  • Пуши, разрешения и платёжная шторка — всё, что живёт за пределами самого приложения.
  • Интеграционные тесты, которые гоняют настоящее приложение на настоящем устройстве.
  • Публикация в обоих магазинах; аккаунты и ключи подписи оформлены на ваше имя.
  • Шесть месяцев после сдачи: ошибки в сделанном правим за свой счёт.

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

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

И одно ограничение, о котором лучше знать заранее. Сроки проверки в магазинах мы не гарантируем: их назначают Apple и Google, и повлиять на них ни мы, ни вы не можем.

Что оставить на потом

Список того, что в первый релиз не входит, так же важен, как список того, что входит:

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

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

Хороший пример того, как большой продукт раскладывается на этапы, — наш разбор маркетплейса, где деньги лежат посередине. Весь продукт занял четыре месяца от старта до работающей версии. Столько времени ушло потому, что эскроу, арбитраж, водяные знаки и ИИ-студия с оплатой за генерацию были отдельными этапами, каждый со своим объёмом работ.

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

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

Одна платформа или сразу две

Частый вопрос — не начать ли с одной платформы, чтобы сэкономить. Бывает и обратная ситуация: заказчику посчитали iOS и Android отдельно, и сумма удвоилась. Иногда два нативных приложения — правильный ответ. Но гораздо чаще это две кодовые базы и два набора ошибок на один продукт.

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

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

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

Сколько стоит и сколько длится

MVP мобильного приложения — первый релиз с одним рабочим сценарием на обеих платформах — стоит от 800 000 ₽ и занимает восемь недель: от первого созвона до сборки, которую ваши клиенты могут установить. Это дороже веб-версии намеренно: две платформы, два ревью в магазинах и прогоны на живых устройствах. Дальше цену определяют деньги внутри продукта (депозиты, выплаты, возвраты), количество ролей и интеграции, а не количество экранов.

Как устроены деньги и сроки:

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

Для масштаба сравните с полным продуктом. Двусторонний маркетплейс — это две стороны со своими сценариями, путь денег между ними и админка, которая всё это разводит. Первая версия такого продукта стоит от 1 200 000 ₽ и делается за двенадцать недель, а мобильные приложения для обеих сторон в неё не входят: это следующая фаза, со своими восемью неделями и своей ценой. Одна мобильная половина стоит от 800 000 ₽ и делается за восемь недель, как и первый релиз. А маркетплейс из нашего разбора со всеми отдельными этапами занял четыре месяца.

С чего начать

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

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