Сколько стоит и сколько длится разработка MVP

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

Что такое MVP и чем он НЕ является

MVP (minimum viable product) — это минимальная версия продукта, которая уже проверяет одну ключевую гипотезу на реальных пользователях и способна собрать честную обратную связь. Ключевые слова здесь — «минимальная» и «жизнеспособная» одновременно. Не прототип в Figma, не лендинг «оставьте заявку», а работающий продукт, за использование которого кто-то готов платить или хотя бы регулярно возвращаться.

Чем MVP НЕ является:

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

Практическое правило: если фичу нельзя привязать к проверяемой гипотезе («пользователи готовы платить за X», «люди будут возвращаться ради Y»), в MVP она не входит.

Из чего складывается срок и цена

Стоимость MVP почти линейно зависит от объёма фич — но не в штуках экранов, а в количестве самостоятельных пользовательских сценариев и интеграций с внешними системами. Каждая интеграция (платёжка, CRM, мессенджер, внешний API) — это не только код, но и обработка ошибок, повторные попытки, тестирование крайних случаев. Именно интеграции чаще всего съедают срок незаметно.

Основные драйверы бюджета:

• Количество ролей. Один тип пользователя дешевле, чем связка «клиент + админ + модератор»: каждая роль — это свой набор экранов и прав доступа.
• Кастомный дизайн против готовой UI-библиотеки. Индивидуальный дизайн каждого экрана добавляет недели. MVP на компонентной системе выглядит достойно и стоит кратно дешевле.
• Сложность бизнес-логики. Форма с валидацией — это дни. Движок расчётов, состояний, воронок — это недели-месяцы.
• Интеграции. Одна платёжка + одна CRM — норма для MVP. Пять внешних систем — уже не MVP.
• Нефункциональные требования. Нагрузка, отказоустойчивость, аудит, соответствие требованиям — всё это оправдано позже, но на старте часто закладывается зря.

Ориентировочные рыночные вилки (Россия/СНГ, аутсорс-студия, 2025–2026, сильно зависят от стека и региона):

• Простой MVP (1 роль, 3–5 экранов, 1 интеграция): условно от 300–600 тыс. ₽, 4–8 недель.
• Средний MVP (2 роли, платежи + CRM, личный кабинет, базовая аналитика): 700 тыс. – 2 млн ₽, 8–14 недель.
• Сложный MVP (мультитенант, нетривиальная логика, несколько интеграций, AI-компонент): 2–5 млн ₽, 3–6 месяцев.

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

Этапы: дискавери → дизайн → разработка → запуск

Любой честный MVP-проект проходит четыре стадии. Экономить можно на объёме каждой, но не пропускать целиком.

Дискавери (0.5–2 недели)

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

Дизайн (1–3 недели)

UX-каркас ключевого флоу и визуал на базе компонентной системы. Для MVP почти всегда достаточно готового дизайн-фреймворка с лёгкой брендизацией — рисовать уникальную иконку для каждого состояния кнопки на этом этапе нерационально.

Разработка (3–12 недель)

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

Запуск (0.5–2 недели)

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

Как урезать скоуп и запуститься быстрее

Самый эффективный рычаг сокращения срока — не «писать код быстрее», а «писать меньше кода». Проверенные приёмы:

• Одна гипотеза — один сценарий. Всё, что не проверяет главную гипотезу, уходит в бэклог. Регистрация через email вместо пяти способов входа. Одна платёжка вместо трёх.
• Ручные операции вместо автоматизации. Если заявок будет 10 в день, менеджер обработает их вручную — не нужен движок автоматизации на старте. Автоматизируют то, что уже болит от объёма.
• Готовые сервисы вместо своей разработки. Аутентификация, платежи, рассылки, аналитика — берутся из коробки. Своё пишут только там, где в этом и состоит ценность продукта.
• Компонентная UI-библиотека вместо кастома. Экономит недели дизайна и вёрстки без потери качества.
• No-code для гипотез, где он уместен. Иногда квиз, бот или таблица проверяют гипотезу за дни. Наш кейс GlassQuote показывает, как узкий калькулятор-квиз закрывает конкретную бизнес-задачу без тяжёлого бэкенда.

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

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

Архитектура и мультитенантность: что закладывать сразу

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

Разумный баланс для старта:

• Модульный монолит. Один разворачиваемый сервис с чёткими границами внутри. Быстро разрабатывается, легко деплоится, при росте безболезненно распиливается на части. Для 90% MVP это правильный выбор.
• Мультитенантность — если она в бизнес-модели. Если продукт с первого дня обслуживает несколько компаний-клиентов (B2B SaaS), изоляцию данных по тенантам дешевле заложить сразу, чем встраивать потом в живую базу. Если продукт для одного клиента — мультитенантность не нужна, это преждевременное усложнение.
• Чистые границы данных и понятная схема. Даже в простом MVP стоит потратить время на аккуратную модель данных: переписать код проще, чем мигрировать данные пользователей.
• Готовность к деплою и наблюдаемости с первого дня. Логи, базовый мониторинг, воспроизводимая сборка — это не «энтерпрайз», а гигиена, которая экономит нервы на запуске.

Ориентир простой: закладывайте архитектуру под следующий год роста, а не под гипотетический IPO. Пример продукта, где мультитенантность и чистая доменная модель были осознанным решением с самого старта, — кейс WoodPlay.

Хорошая новость: правильная умеренная архитектура почти не удорожает MVP относительно «наколеночной» — разница в дисциплине команды, а не в человеко-часах. А вот преждевременная сложность (лишние сервисы, кластеры, оркестрация) удорожает проект вдвое и замедляет каждую последующую фичу. Общий принцип избегания преждевременной оптимизации хорошо сформулирован в C2 wiki про YAGNI — «you aren't gonna need it» ровно про архитектурные украшения в MVP.

FAQ

Сколько в среднем стоит разработка MVP?

Средний веб-MVP с двумя ролями, оплатой и личным кабинетом в аутсорс-студии — это ориентировочно 700 тыс. – 2 млн ₽. Простой продукт с одним сценарием может уложиться в 300–600 тыс. ₽, а сложный с мультитенантностью и несколькими интеграциями — 2–5 млн ₽. Точная цифра зависит от количества сценариев, интеграций и того, сколько скрытой сложности вскроется на дискавери, поэтому финальную оценку дают только после проработки требований.

Сколько времени занимает разработка MVP?

Реалистичный диапазон — от 4–8 недель для простого MVP до 3–6 месяцев для сложного. Средний продукт с платежами и личным кабинетом обычно выходит за 8–14 недель. Если вам обещают «MVP за неделю» — это, скорее всего, лендинг или прототип, а не работающий продукт с бэкендом и интеграциями.

Можно ли сделать MVP дешевле и быстрее заявленных сроков?

Да, за счёт урезания скоупа: один сценарий вместо трёх, готовые сервисы для аутентификации и платежей, компонентная UI-библиотека вместо кастомного дизайна, ручная обработка операций там, где объём это позволяет. Иногда гипотезу проверяет бот или квиз за считанные дни. Экономят на объёме функций, а не на качестве ключевого сценария.

Нужно ли закладывать мультитенантность в MVP?

Только если продукт с первого дня обслуживает нескольких клиентов-компаний (B2B SaaS) — тогда изоляцию данных дешевле встроить сразу. Для продукта под одного заказчика или B2C-аудиторию мультитенантность — преждевременное усложнение. В большинстве случаев правильный старт — модульный монолит, который безболезненно масштабируется при росте.

Почему нельзя пропустить этап дискавери?

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