Разработка MVP приложения у меня начинается от 250 000 ₽. Эта сумма вызывает два противоположных вопроса, и оба справедливые.
«Почему так дорого для первой версии?» — если человек ждал, что минимальный продукт стоит как сайт. И «почему так дёшево?» — если он до этого получал оценки в несколько раз выше и теперь подозревает, что за этой суммой прячется прототип на выброс.
Ответ на оба — в составе работ. Ниже разбираю, что входит в первую версию, что откладывается и почему, и какие вещи двигают смету вверх.
MVP — это объём, а не качество
Начну с того, вокруг чего идёт основная путаница.
MVP — не черновик, не демо и не «приложение попроще». Это работающий продукт, у которого намеренно один сценарий вместо пяти. Тем, что в него вошло, пользуются по-настоящему: если человек не разобрался в интерфейсе и ушёл, вы не узнаете, идея не нужна или просто кнопка была непонятной.
Урезается объём. Качество того, что вошло, урезать нельзя — иначе проверка гипотезы не состоится, а именно ради неё всё и делается. Про то, как этот принцип нарушают и во что это обходится, я разбирал в шести ошибках MVP.
Что входит в разработку MVP
Что входит в MVP, зависит от задачи, но структура одна и та же — шесть частей.
Главный сценарий продукта. Один ключевой путь пользователя от начала до результата — то, ради чего продукт существует. Проектируется и собирается целиком, без второстепенных веток, которые пока не нужны для проверки.
Понятный интерфейс. Чистые экраны под этот сценарий: человеку понятно, что делать, без объяснений и обучения. Минимально — не значит небрежно.
Базовые роли и вход. Если сценарий требует разных ролей — клиент и исполнитель, пользователь и администратор, — закладываются вход и базовые права: каждый видит и делает только своё.
Аналитика и метрики. Подключается с первого дня, чтобы видеть, как люди проходят сценарий и где застревают. Без этого MVP превращается в предмет для споров о вкусах: у всех есть мнение, данных нет ни у кого.
Ключевые интеграции. Только то, без чего сценарий не работает: оплата, уведомления, карта или CRM. Всё остальное ждёт подтверждения спроса.
План развития после запуска. По итогам первой версии собираются приоритеты: что добавлять дальше и в каком порядке. MVP — первый этап продукта, а не отдельная поделка, которую потом выбрасывают.
Шесть пунктов выглядят скромно ровно до того момента, когда начинаешь считать, сколько работы стоит за первым: сценарий «от начала до результата» — это и экраны, и серверная логика, и обработка ошибок, и то, что происходит, когда пользователь делает не то.
Поэтому 250 000 ₽ — не цена за «несколько экранов». В эту сумму входит рабочий путь пользователя целиком: интерфейс, серверная часть, работа с данными, ошибочные ситуации, базовые права и те интеграции, без которых сценарий не завершается. Экранов может быть немного, но каждый из них обязан по-настоящему работать — иначе проверять будет нечего.
Что не входит — и почему это не экономия на вас
Самая полезная часть разговора — и та, которую пропускают в смете.
Второй и третий сценарии. Всё, что не участвует в проверке гипотезы, откладывается. Не отменяется — откладывается, и попадает в план развития.
Роли «на вырост». Администратор, модератор, партнёр, супервайзер — каждая роль добавляет права, экраны и состояния. Если сценарий проверяется без неё, она ждёт.
Админка на все случаи. В административной панели нередко больше экранов, чем в пользовательской части. В первую версию входит то, без чего нельзя работать, а не интерфейс настройки всего на свете.
Интеграции, без которых главный сценарий работает. Бухгалтерия, склад, рассылки, вторая CRM — всё это подключается тогда, когда понятно, что продукт нужен.
Расширенная дизайн-система и сложная визуальная проработка. Собственная графика, иллюстрации, анимация — отдельная и заметная статья бюджета. Вопрос к себе простой: у вас внешний вид продаёт или продуктом пользуются по необходимости?
Аккаунты разработчика в сторах и платные внешние сервисы. Оформляются на вас и оплачиваются отдельно — карты, рассылки, тарифы сторонних API. Это не подвох и не мелкий шрифт: аккаунты и внешние сервисы принадлежат заказчику. Важно только, чтобы это было известно до старта, а не выяснилось после оценки.
Ни один из этих пунктов не означает «мы не будем это делать». Он означает: этого нет в первой сумме, и вы знаете об этом заранее.
MVP, прототип и демо — три разные вещи
Одним словом «MVP» называют продукты, которые отличаются на порядок по стоимости. Прежде чем сравнивать оценки, стоит убедиться, что речь об одном и том же.
Прототип — кликабельные экраны без начинки. Данные не сохраняются, оплата не проходит, серверной части нет. Полезен, чтобы показать идею инвестору, проверить логику интерфейса на людях и собрать первые реакции. Чего он не заменяет — проверки работающего продукта в реальном сценарии: пользоваться прототипом по-настоящему нельзя.
Демо — то же самое, но с подставленными данными: выглядит как работающее приложение, внутри сценарий не выполняется.
MVP — работающий продукт с главным сценарием: данные действительно сохраняются, нужные действия выполняются до результата, необходимые интеграции работают, а поведение людей можно измерить. Им пользуются по-настоящему, поэтому его выводы чего-то стоят.
Разница в цене между прототипом и MVP — это не разница в подходе подрядчика. Это разная работа: у первого нет серверной части, обработки ошибок, ролей и интеграций, то есть всего того, что и составляет основную часть сметы. Когда одна оценка вдвое ниже другой, первым делом стоит проверить не подрядчика, а то, что именно каждый из них назвал словом «MVP».
Что двигает смету вверх
Разработка MVP проекта дорожает не от количества экранов, а от того, что за ними стоит. На старте цену определяют четыре вещи.
Число ролей. Приложение, где пользователь один, устроено принципиально иначе, чем приложение, где есть клиент, исполнитель и администратор: у каждой роли свои экраны, права и сценарии.
Оплаты внутри продукта. Кнопка оплаты — это не кнопка: ошибки, повторные операции, возвраты, изменение статуса заказа. Подписки и частичные оплаты — отдельный уровень.
Интеграции с чужими системами. Разобраться в логике чужой системы, её ограничениях и способе синхронизации занимает больше времени, чем написать код на своей стороне. Наличие API — только половина дела.
Чувствительность данных. Чем чувствительнее то, что вы храните, тем больше требований к разграничению доступа, хранению, журналированию действий и защите. Персональные, финансовые и медицинские данные добавляют работы во всех четырёх местах сразу.
Это факторы старта. Полный разбор того, что двигает бюджет приложения на дистанции, у меня в разборе стоимости разработки приложения для iOS и Android — там девять факторов и то, как они складываются.
Сколько это занимает
Скажу честно и без чисел: MVP с одним главным сценарием — это ориентировочно несколько недель, полноценный продукт заметно дольше. Точный срок называется после разбора задачи, и вот почему я не называю его раньше: он зависит от числа ролей, интеграций и требований к данным сильнее, чем от размера сметы.
Полезнее другого правила тут нет: срок определяется не тем, сколько функций удалось выбросить, а тем, сколько связей осталось в главном сценарии. Один пользователь и одна заявка — это короткая работа. Клиент, исполнитель, оплата и уведомления в одном сценарии — заметно длиннее, хотя список функций на бумаге вырос всего вчетверо.
Работа идёт четырьмя этапами: разбираем идею и главный сценарий → проектируем минимум → собираем и подключаем → запускаем и смотрим на данные. На выходе каждого есть то, что можно посмотреть, а не отчёт о проценте готовности.
Кому хватит первой версии, а кому нет
Честный разговор про границу.
MVP на заказ подходит, если гипотезу можно проверить одним сценарием: люди приходят, делают главное действие, возвращаются. Спрос не подтверждён, и вкладывать сразу в полноценный продукт — значит платить за функции, о которых вы пока ничего не знаете. Заказать разработку MVP в такой ситуации дешевле не потому, что работа проще, а потому, что вы покупаете ответ на вопрос, а не набор догадок о будущем.
MVP не подойдёт, если без нескольких ролей и интеграций процесс физически не заработает. Бывают задачи, где «минимальная версия» — это уже почти полный продукт: логистика с курьерами и диспетчерами, медицина с записью и картами пациентов, маркетплейс, где без обеих сторон ничего не происходит. В таких случаях честнее сказать это сразу и считать другой формат, а не резать до состояния, в котором проверять нечего.
Как устроена первая версия и что получается на выходе — на странице разработки MVP; там же реальный проект, собранный по этому принципу.
Что дальше
Чтобы оценить MVP, мне не нужен готовый список функций и тем более техническое задание. Достаточно двух вещей: что пользователь должен сделать в продукте и какой результат вы хотите проверить. По этому сценарию уже видно, что обязано войти в первую версию, а что спокойно ждёт второй.
Три формата запуска и их состав — на странице цен. Там же видно, где заканчивается MVP и начинается веб-приложение или полноценный мобильный продукт: иногда после разбора выясняется, что задача с самого начала жила в соседней колонке.