Разработка

MVP в 2026: реальные сроки, бюджет и что резать без потерь

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

Команда Veltos.Tech13 мая 2026 г.14 мин чтения

Коротко

Типичный бюджет MVP на российском рынке в 2026 году — 700 000–3 500 000 ₽. No-code-версия собирается от 4 недель, MVP на готовых компонентах — за 6–10 недель, кастомный кроссплатформенный продукт — за 3–4 месяца, сложный с интеграциями и платежами — 4–6 месяцев. В Veltos.Tech веб-приложение начинается от 300 000 ₽, мобильное — от 500 000 ₽.

Что такое MVP в 2026 и почему «дёшево и криво» стало опасным

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

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

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

Четыре уровня MVP: сроки и бюджеты

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

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

Третий уровень — кастомный кроссплатформенный продукт: собственный дизайн, мобильное приложение и веб одновременно, свой бэкенд, роли пользователей. Три-четыре месяца. Четвёртый — сложный MVP с интеграциями: подключение внешних систем, платежи с проверками, документооборот, требования по безопасности данных. Четыре-шесть месяцев и верхняя граница бюджета. Рыночный ориентир по всем уровням — 700 000–3 500 000 ₽, и внутри этой вилки цена определяется в основном количеством внешних систем.

Уровень MVP	Срок	Бюджет (рынок)	Какую гипотезу проверяет
No-code сборка	от 4 недель	150 000–500 000 ₽	Есть ли спрос и платят ли за это вообще
MVP на готовых компонентах	6–10 недель	700 000–1 500 000 ₽	Работает ли сценарий и удерживает ли продукт
Кастомный кроссплатформенный	3–4 месяца	1 500 000–2 500 000 ₽	Готовы ли платить за качество опыта
Сложный с интеграциями и платежами	4–6 месяцев	2 500 000–3 500 000 ₽ и выше	Встраивается ли продукт в реальный процесс

Уровни MVP: срок, бюджет и подходящая гипотеза

Как резать объём: три корзины функций

Работающая методика простая. Выпишите все функции, которые пришли в голову, и разложите по трём корзинам. Первая: «проверяет гипотезу» — без этого эксперимент бессмысленен. Вторая: «делает продукт пользуемым» — без этого человек не дойдёт до первой корзины. Третья: «можно потом» — всё остальное. В третьей корзине обычно оказывается 60–70% первоначального списка, и это нормально, а не признак слабой идеи.

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

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

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

Что нельзя вырезать ни при каком бюджете

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

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

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

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

No-code или код: и сколько стоит уйти с no-code потом

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

Тарифы заслуживают отдельного внимания, потому что no-code часто дорожает нелинейно. Платформы считают деньги за записи в базе, за выполненные операции автоматизации, за активных пользователей. Пока их сотни, стоимость незаметна. При десятках тысяч записей и активных сценариях ежемесячный счёт может вырасти до сумм, при которых собственная разработка окупилась бы за год. Это не аргумент против no-code — это аргумент за то, чтобы посчитать стоимость на прогнозируемом объёме, а не на текущем.

Главная скрытая статья — стоимость переезда. Из no-code переносятся данные, но не переносится логика: сценарии автоматизации, правила доступа, формулы и интерфейс придётся воспроизводить с нуля. По рынку это означает практически полную стоимость новой разработки плюс работы по миграции данных. То есть no-code-этап нужно закладывать как расход, который вы, скорее всего, спишете, а не как первую версию продукта, которая будет развиваться.

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

Бюджет за пределами разработки

Разработка — это обычно 55–70% реального бюджета запуска, и основатели регулярно планируют только её. Дизайн идёт отдельной строкой и на MVP занимает 15–25%: продуктовый дизайнер нужен не для красоты, а для того, чтобы узкий набор функций не выглядел обрубком. Аналитика и настройка трекинга — ещё несколько дней работы. Инфраструктура: серверы, база, домены, почтовый сервис, мониторинг — от 5 000 до 40 000 ₽ в месяц на старте.

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

Самая недооценённая статья — первые три месяца после запуска. MVP не заканчивается релизом, он с релиза начинается: приходят данные, находятся дыры в сценариях, выясняется, что половина пользователей идёт другим путём. Заложите на итерации 30–50% от бюджета разработки. Без этого резерва вы получите продукт, который нечем улучшить, и данные, на которые нечем ответить — а именно этот этап и создаёт всю ценность эксперимента.

Дизайн: 15–25% бюджета, без него узкий MVP выглядит незаконченным.
Инфраструктура и мониторинг: 5 000–40 000 ₽ в месяц на старте.
Магазины приложений: 2–3 недели на первую публикацию, включая RuStore.
Юридический пакет: оферта, политика данных, уведомление регулятору.
Итерации первых трёх месяцев: 30–50% от бюджета разработки.

Метрики успеха, которые определяют до старта разработки

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

Хорошая метрика конкретна, измерима автоматически и связана с деньгами. «Пользователям нравится» — не метрика. «40% зарегистрировавшихся возвращаются на седьмой день» — метрика. «Стоимость привлечения платящего пользователя ниже 2 500 ₽ при среднем чеке 4 000 ₽» — метрика, по которой можно принимать решение о следующем раунде инвестиций в продукт.

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

Частые вопросы

Можно ли действительно сделать MVP за 30 дней?

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

Сколько стоит MVP мобильного приложения?

На российском рынке кроссплатформенный MVP мобильного приложения обычно укладывается в 1 500 000–2 500 000 ₽ и занимает 3–4 месяца. Если нужны платежи, интеграция с внешними системами или работа с чувствительными данными, бюджет уходит в 2 500 000–3 500 000 ₽ и выше. В Veltos.Tech мобильная разработка начинается от 500 000 ₽ — это узкий продукт с ограниченным набором экранов. Учитывайте отдельно расходы на публикацию: аккаунты разработчика, материалы для сторов и две-три недели на прохождение модерации.

Что делать, если инвестор просит показать продукт, а бюджета почти нет?

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

Нужен ли дизайнер для MVP или хватит готового шаблона?

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

Что входит в MVP, а что точно нет?

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

Нужна помощь с этой задачей?

Мы делаем это на практике, а не только пишем об этом. Опишите задачу — разберём и пришлём смету по этапам.

Обсудить проект