Что нужно знать до начала
Это инженерный материал о структуре MVP-проекта: что входит, что не входит, какие сроки и стоимости реалистичны. Конкретные цены, сроки и состав работ всегда зависят от scope и обсуждаются отдельно — цифры в тексте даны как ориентиры рынка, а не как фиксированная оферта. Юридические аспекты (152-ФЗ, лицензии, договоры) — это не юридическая консультация: их формулировки сверяйте со своим юристом.
Слово «MVP» за последние годы стёрлось почти до бессмысленности. Им называют слайды, фигму, лендинг на Tilda и, изредка, действительно работающий продукт. Из-за этого разговор фаундера с подрядчиком часто начинается с того, что под одним и тем же термином каждый понимает своё, — и заканчивается срывом сроков и сметы.
Эта статья — попытка вернуть точность. Что такое MVP на самом деле, что значит «production-ready», что реально помещается в шесть недель, а что в двенадцать, сколько это стоит и почему, и — едва ли не самое важное — что в MVP не входит и входить не должно.
01 · «MVP» развели до лендинга на Tilda — давайте определимся
Начнём с того, чем MVP не является. Лендинг на Tilda — это не MVP. Это отличный инструмент, но он решает другую задачу: проверяет спрос и формулировки. Лендинг отвечает на вопрос «готовы ли люди оставить заявку или предоплату за эту идею». Это ценно, но это тест гипотезы спроса, а не продукт.
Прототип в Figma — тоже не MVP. Это проверка того, как продукт ощущается, до того как в него вложены деньги на разработку. Кликабельный макет помогает увидеть логику экранов, но в нём нет ни одной реальной строчки данных.
MVP (minimum viable product) — это работающий продукт с одним замкнутым циклом ценности, которым могут пользоваться настоящие пользователи на настоящих данных. Ключевые слова здесь — «работающий», «настоящие пользователи» и «настоящие данные». Если пользователь не может зарегистрироваться, сделать главное действие, ради которого продукт существует, и получить результат — это ещё не MVP, как бы красиво оно ни выглядело.
А production-ready MVP — это MVP, который можно безопасно запустить в продакшен: с авторизацией, ролями, нормальной базой, развёрнутой инфраструктурой и мониторингом. Не «работает у меня на ноутбуке», а «работает в интернете, для чужих людей, и не разваливается в первую неделю».
Разница между этими четырьмя вещами — это не педантизм. Это разница между «мы потратили месяц и три миллиона и теперь надо всё переписывать» и «у нас есть продукт, на котором можно расти».
02 · Что значит production-ready: по пунктам
«Production-ready» звучит как маркетинговое прилагательное, но за ним стоит конкретный технический минимум. Вот что реально входит в первую версию, которую не стыдно показать пользователям и инвесторам.
- Авторизация. Регистрация, вход, восстановление пароля, безопасное хранение учётных данных (хеширование, а не пароли в открытом виде), управление сессиями. Это фундамент, без которого нет «настоящих пользователей».
- Роли и разграничение доступа. Минимум — пользователь и администратор; чаще больше. Role-based access control, при котором каждый видит и может делать только то, что ему положено. Без этого продавец видит чужие заказы, а обычный пользователь может зайти в админку.
- Реальная база данных. Не данные в памяти, которые исчезают при перезапуске, а полноценная СУБД со спроектированной схемой, миграциями и резервными копиями. Бэкапы — это часть production-ready, а не «потом добавим».
- Админ-панель. Интерфейс, в котором заказчик сам может управлять контентом, пользователями и заявками — без того чтобы дёргать разработчика по каждому изменению. Отсутствие админки превращает запуск в постоянную зависимость от подрядчика.
- Деплой и инфраструктура. Настроенный CI/CD, нормальный хостинг, разделение окружений (staging и production), привязанный домен, SSL. Это то, что отделяет «продукт в интернете» от «папки с кодом».
- Мониторинг и логирование. Отслеживание ошибок (например, Sentry), мониторинг доступности, логи. Когда что-то ломается — а оно ломается, — вы должны узнать об этом раньше пользователя.
Сверх этого минимума production-ready подразумевает базовую безопасность (HTTPS, валидация ввода, защита от перебора, аккуратное хранение секретов), адаптивную вёрстку под мобильные, базовую аналитику и юридический минимум. Для российского запуска сюда же относится соответствие 152-ФЗ «О персональных данных»: согласие на обработку, политика конфиденциальности, корректное хранение. Это не юридическая консультация — конкретику стоит уточнить у юриста, — но игнорировать эти требования на запуске нельзя.
Главное определение, которое стоит держать в голове: production-ready — это не «идеально», «масштабируемо на миллионы» или «со всеми функциями». Это «реальные пользователи могут безопасно этим пользоваться, вы можете это эксплуатировать, и на этом можно строить дальше».
03 · Scope на 6 недель против scope на 12 недель
Срок MVP — это не оценка «сколько займёт работа», а ограничение, под которое подбирается объём. Срок фиксирован, гибким остаётся scope. Поэтому правильный разговор звучит не «сколько вы будете делать мой продукт», а «что из моего продукта поместится в 6 недель, а что в 12».
Шесть недель — это один пользовательский цикл ценности, доведённый до ума. Как правило, одна-две роли, необходимая авторизация, минимальная админка, один отполированный «счастливый путь» от входа до результата, плюс деплой и мониторинг. Это формат для фаундера, который точно знает ту единственную гипотезу, которую хочет проверить на живых пользователях. Шесть недель не прощают расфокуса: каждая лишняя функция вытесняет что-то из обязательного минимума.
Двенадцать недель — это уже продукт с несколькими ролями (обычно от двух до четырёх), более полными сценариями, интеграцией платежей, более содержательной админкой, обработкой части пограничных случаев, уведомлениями, базовым поиском и фильтрацией. Это формат для двусторонних продуктов, маркетплейсов и всего, что вы собираетесь не только показать инвесторам, но и дать платящим пользователям. Двенадцать недель — это не «в два раза больше функций», это другой класс продукта с реальной операционной устойчивостью.
Ошибка, которая убивает оба формата одинаково, — попытка втиснуть двенадцатинедельный scope в шестинедельный срок «потому что бюджет». Результат всегда один: либо сдвиг сроков, либо урезание именно той части, которую урезать нельзя, — production-readiness. Дисциплина scope важнее скорости рук.
04 · Архитектура до кода
Здесь — главное расхождение между студией, которая мыслит инженерно, и подрядчиком, который сразу «начинает кодить». До первой строчки кода должно появиться несколько вещей: модель данных, ключевые сценарии, выбор технологий под конкретную задачу (а не «то, что мы всегда делаем»), план инфраструктуры и — отдельно — явно очерченные границы scope.
Этому посвящён архитектурный спринт — короткий этап перед разработкой, который снимает главные риски проекта. После него вы знаете, что именно строится, оценка перестаёт быть фантазией, а вероятность дорогостоящего переписывания через два месяца резко падает. Парадокс в том, что архитектура «до кода» не удлиняет проект, а сокращает его: время, потраченное на проектирование, многократно возвращается за счёт того, что не пришлось переделывать.
Попытка сэкономить на этом этапе — самая дорогая экономия в разработке. Код, написанный без архитектуры, почти всегда приходится выбрасывать ровно тогда, когда у продукта появляются первые настоящие пользователи и первые настоящие нагрузки.
05 · Прозрачность стоимости: от 500 000 ₽
Честный разговор о деньгах короче, чем кажется. Стоимость MVP определяют три вещи: scope (сколько ролей и сценариев), интеграции (платежи, внешние сервисы) и глубина дизайна. Сфокусированный production-ready MVP начинается от 500 000 ₽; маркетплейс с несколькими ролями, платежами и более полными сценариями за двенадцать недель стоит соответственно дороже. Это не «цена за продукт вообще», а стартовая точка, от которой смета растёт вместе с объёмом — и это нормально.
Важнее понять, на чём экономить нельзя. Попытка убрать из сметы архитектурный спринт или production-readiness кажется способом сэкономить, но на деле это перенос затрат в будущее с процентами: переписывание, простои, потеря данных и потеря доверия инвесторов обходятся в разы дороже сэкономленного. Дешёвый MVP, который нельзя запустить и нельзя развивать, — это не сэкономленные деньги, а выброшенные.
06 · Что НЕ входит в MVP
Едва ли не главная ценность зрелого подрядчика — умение сказать «это в MVP не нужно». Вот что осознанно остаётся за рамками первой версии и добавляется уже после того, как ядро продукта подтвердило свою ценность.
- Нативное мобильное приложение. На старте почти всегда правильнее адаптивный веб или PWA: он покрывает и десктоп, и мобильные, разрабатывается быстрее и не требует прохождения модерации в сторах. Нативное приложение — это отдельный проект, который имеет смысл, когда веб-продукт уже работает.
- Сложный AI/ML. Если искусственный интеллект — это и есть ядро ценности продукта, его делают. Но кастомные ML-пайплайны, обучение моделей и тяжёлая аналитика «чтобы было модно» в MVP не входят — это дорого, долго и почти всегда преждевременно.
- Корпоративные интеграции. Глубокая интеграция с 1С, ERP, SSO/SAML, сложные обмены с внешними учётными системами — это мир enterprise, а не первой версии. Такие интеграции добавляют недели и существенный риск ради сценариев, которых у вас на старте ещё нет.
- Исчерпывающая обработка пограничных случаев и оптимизация под масштаб. В MVP отрабатывается основной путь и разумный минимум ошибок. Оптимизация под миллионы пользователей, экзотические сценарии и тяжёлые отчётные дашборды — это задачи, которые решают, когда появляются реальные пользователи и реальные данные, показывающие, что именно оптимизировать.
Логика во всех случаях одна: эти вещи не «хуже» — они просто относятся к этапу после валидации. Добавлять их до того, как ядро продукта доказало право на жизнь, — значит платить за функциональность, которая может никогда не понадобиться.
07 · Реальный пример: маркетплейс с тремя ролями за 10 недель
Чтобы абстракция стала конкретной, разберём типовую конфигурацию — двусторонний маркетплейс с тремя ролями, собранный за десять недель.
Роли: покупатель, продавец и администратор, с полноценным разграничением доступа. Продавцу — управление своими товарами или услугами (создание, редактирование, снятие с публикации). Покупателю — просмотр, поиск и фильтрация каталога, оформление заказа. Между ними — транзакционный слой: заказы, статусы, интеграция платежей. Администратору — панель модерации: проверка объявлений, управление пользователями, разрешение спорных ситуаций. Сверху — авторизация, развёртывание в продакшен, мониторинг и бэкапы.
Что сознательно отложили на «после MVP»: нативное мобильное приложение, рекомендательные алгоритмы, развитый внутренний мессенджер (на старте хватило базовых уведомлений), аналитические дашборды. Каждая из этих вещей была бы уместна — но позже, когда поток реальных сделок покажет, что именно из этого действительно нужно.
Грубая раскладка по времени: первые недели — архитектурный спринт и модель данных, затем ядро (роли, авторизация, каталог), затем транзакции и платежи, затем админка, и финальные недели — стабилизация, деплой и мониторинг. Десять недель — это реалистичный, а не героический срок именно потому, что границы scope были зафиксированы на старте и не расползались по ходу.
(Пример иллюстративный и собирательный: это типичная конфигурация подобных проектов, а не описание конкретного клиента.)
08 · Что показывают инвесторам на технической проверке
Когда продукт доходит до раунда, инвесторы — или приглашённые ими технические эксперты — проводят technical due diligence. И смотрят они не на слайды. Вот что реально проверяют.
Во-первых, есть ли работающий продукт, а не презентация. Production-ready MVP с реальными пользователями и реальными данными — это сам по себе сигнал, что команда умеет доводить до результата. Лендинг на Tilda такую проверку не проходит.
Во-вторых, кому принадлежит код. Это частый и болезненный вопрос: интеллектуальные права на код и инфраструктуру должны принадлежать вам, а не подрядчику. Аккаунты (домен, хостинг, репозиторий) — на ваших данных. Если это не так, сделка может застопориться именно здесь.
В-третьих, состояние архитектуры: можно ли на этом расти или всё придётся переписывать. Здесь окупается тот самый архитектурный спринт — продукт, спроектированный с самого начала, проходит проверку спокойно.
В-четвёртых, базовая безопасность и эксплуатируемость: нет ли критических дыр, есть ли мониторинг, бэкапы, налажен ли деплой, насколько быстро команда может выкатывать изменения.
Итог простой и связывает всю статью воедино. Production-ready MVP — это не только продукт, которым можно пользоваться сегодня, но и актив, который выдерживает техническую проверку завтра. Это и есть разница между первой версией, на которой строят компанию, и красивой обёрткой, которую приходится выбрасывать на первом же серьёзном разговоре.
Итог
«MVP» как термин стёрся — но за ним по-прежнему есть конкретный инженерный смысл. Это не лендинг, не прототип и не «соберём и потом доделаем». Это работающий продукт с замкнутым циклом ценности, который можно безопасно запустить в продакшен: с авторизацией, ролями, нормальной базой, инфраструктурой и мониторингом.
В шесть недель помещается один сценарий, доведённый до ума; в двенадцать — продукт с несколькими ролями и платежами. Срок фиксирован, гибким остаётся scope — и дисциплина границ важнее скорости рук. Архитектура «до кода» — не задержка, а экономия: она отделяет MVP, на котором можно расти, от MVP, который придётся переписывать.
Стоимость начинается от 500 000 ₽ и масштабируется со scope. Экономия за счёт production-readiness или архитектурного спринта — это не экономия, а перенос затрат в будущее с процентами. А самое ценное умение зрелого подрядчика — сказать, что в первую версию не нужно: нативное приложение, кастомный AI, корпоративные интеграции, оптимизация под миллионы. Эти вещи появляются после валидации, а не до.
Если на выходе у вас продукт, которым пользуются настоящие люди, который вы спокойно эксплуатируете и который проходит технический due diligence инвестора, — задача MVP выполнена. Дальше — рост.
Частые вопросы
Чем MVP отличается от лендинга на Tilda? Лендинг — это тест гипотезы спроса: проверка, готовы ли люди оставить заявку или предоплату за идею. MVP — это работающий продукт с замкнутым циклом ценности, которым пользуются настоящие пользователи на настоящих данных. Лендинг не выдерживает технической проверки инвестором, MVP — да.
Что значит «production-ready» MVP? Это технический минимум, при котором первую версию можно безопасно запустить в продакшен: авторизация, роли и разграничение доступа, реальная база с бэкапами, админ-панель, CI/CD и инфраструктура, мониторинг и логирование. Плюс базовая безопасность, адаптивная вёрстка и юридический минимум (включая соответствие 152-ФЗ для российского запуска).
Сколько стоит MVP за 6–12 недель? Стартовая точка для сфокусированного production-ready MVP — от 500 000 ₽. Финальная смета зависит от scope (количество ролей и сценариев), интеграций (платежи, внешние сервисы) и глубины дизайна. Маркетплейс с несколькими ролями и платежами за двенадцать недель стоит соответственно дороже. Это не фиксированная оферта, а ориентир — точная цена обсуждается после архитектурного спринта.
Что входит в MVP, а что — нет? Входит: один замкнутый цикл ценности с нужными ролями, авторизация, БД, админка, деплой и мониторинг. НЕ входит на старте: нативное мобильное приложение (его заменяет адаптивный веб или PWA), кастомный AI/ML (если ИИ не ядро продукта), глубокие корпоративные интеграции (1С, ERP, SSO/SAML), исчерпывающая обработка пограничных случаев и оптимизация под масштаб.
Можно ли сделать MVP за 2–3 недели? За 2–3 недели реально сделать прототип или MVP с очень узким одним сценарием без production-readiness. Полноценная первая версия с авторизацией, ролями, БД, админкой и развёрнутой инфраструктурой требует минимум 6 недель — попытка ужать этот объём в меньший срок обычно означает урезание именно production-readiness, то есть запуск без бэкапов, мониторинга или нормальной БД.
Зачем перед MVP нужен архитектурный спринт? Чтобы зафиксировать модель данных, ключевые сценарии, выбор стека и план инфраструктуры до того, как начат код. Спринт занимает немного времени и стоит существенно меньше, чем переделка через два месяца. Без него оценка проекта — фантазия, а вероятность переписывания после первых настоящих пользователей резко растёт.
Что инвестор проверяет на technical due diligence? Четыре вещи: есть ли работающий продукт (а не презентация), кому принадлежат код и инфраструктурные аккаунты, в каком состоянии архитектура (можно ли на этом расти или всё переписывать), и базовая безопасность с эксплуатируемостью (нет ли критических дыр, есть ли мониторинг, бэкапы, налажен ли деплой). Лендинг на Tilda эту проверку не проходит — production-ready MVP проходит.
Если вы на этапе, когда нужно превратить идею в работающий продукт за фиксированный срок и с понятной сметой, — это ровно та задача, под которую устроена наша разработка MVP. Начать имеет смысл с архитектурного спринта: он стоит недорого, занимает немного времени и даёт честную оценку всего проекта ещё до того, как написана первая строчка кода.