# Что такое MVP на самом деле и чем он не является

> Что такое MVP простыми словами: самая маленькая вещь, которая проверяет самое рискованное предположение. Чем MVP отличается от прототипа и v1.

Published: 2025-03-25 · Source: https://subxcat.com/ru/articles/what-is-mvp · Author: SUBXCAT

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

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

## Главное слово — «предположение»

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

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

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

## Что такое MVP по сравнению с прототипом и v1

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

- **Прототип** отвечает на вопрос «как это может выглядеть и работать?». По нему кликают, его показывают, но реальной ценности он не создаёт. Кликабельный макет, демо на выдуманных данных.
- **MVP** отвечает на вопрос «нужно ли это людям так, как мы думаем?». Им пользуются по-настоящему, даже если внутри всё держится на ручной работе и таблицах.
- **v1** отвечает на вопрос «можем ли мы поставлять это стабильно?». Это уже продукт, который выдерживает рост, платежи, поддержку и требования безопасности.

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

## Насколько маленьким должен быть MVP

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

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

Но у слова «viable» есть смысл. MVP должен решать проблему достаточно хорошо, чтобы человек захотел вернуться. Если продуктом невозможно пользоваться, отказ ничего не скажет о гипотезе — только о том, что продукт сырой.

## Частые ошибки с MVP

- **Строить то, что легко, а не то, что рискованно.** Интерфейс собирать приятно, поэтому его и собирают. А главный риск — например, продажи — так и остаётся непроверенным.
- **Не решить заранее, что считать успехом.** Без порога любой результат можно истолковать как «в целом неплохо». Запиши до запуска: сколько человек, что они должны сделать и за какой срок.
- **Показывать только друзьям.** Друзья вежливые. Им нравится всё.
- **Считать MVP фундаментом.** Код, написанный ради проверки гипотезы, часто не годится для роста. Это нормально: у него была другая задача. Плохо, когда об этом забывают и строят v1 поверх, ничего не пересматривая.
- **Затягивать.** MVP, который делается полгода, проверяет уже другой рынок и другое терпение.

## Что делать после MVP

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

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

## Коротко

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

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