Когда мы говорим «MVP займёт шесть недель», у заказчика в голове обычно чёрный ящик: деньги ушли, разработчики пропали, через полтора месяца что-то появится. Или не появится.

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

00 · Неделя 0: разбор и границы

Нулевая неделя — до договора и бесплатная. Мы разбираем идею и отвечаем на три вопроса: какую гипотезу проверяем, какой сценарий главный и что не делаем в первой версии.

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

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

01 · Недели 1–2: дизайн и каркас

  • Неделя 1. Проектируем экраны и рисуем дизайн главных сценариев. Параллельно поднимаем инфраструктуру: репозиторий, сервер, базу, сборки.
  • Неделя 2. Собираем каркас приложения: навигация, экраны, переходы. Данные пока условные, но по приложению уже можно ходить.

Демо в конце спринта: вы открываете приложение на своём телефоне и листаете его. Не картинку, не прототип в браузере — настоящую сборку.

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

02 · Недели 3–4: ядро продукта

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

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

Демо: сценарий работает от начала до конца на реальных данных. Вы заводите товар в админке — он появляется в приложении.

03 · Неделя 5: интеграции

Всё, что связывает приложение с внешним миром: оплата, уведомления, карты, аналитика, обмен с учётной системой, если он в составе первой версии.

Это неделя, где чаще всего вылезают сюрпризы — не у нас, а на стороне сервисов: у эквайринга своя модерация, у 1С нет готового API, у сторов свои требования к уведомлениям. Поэтому интеграции идут пятой неделей, а не последней: остаётся запас.

Демо: тестовая оплата проходит, уведомление приходит на телефон, данные видны в аналитике.

04 · Неделя 6: стабилизация и релиз

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

Про ревью — важное: Google Play обычно отвечает за день-два, App Store строже и может развернуть сборку. Мы закладываем это в шестую неделю, но если Apple попросит доработку, релиз сдвигается на несколько дней. Самая частая причина отказов разобрана в статье про правило Minimum Functionality.

Демо: приложение в сторе, вы устанавливаете его как обычный пользователь.

05 · Что не входит в MVP

Шесть недель работают ровно потому, что мы не тащим в первую версию всё подряд. Из MVP обычно вылетает:

  • Вторая платформа. Начинаем с той, где ваша аудитория; вторая добавит 30–40% к мобильной части.
  • Второй тип пользователя. Клиент — да. Клиент + исполнитель + оператор — это уже система, а не MVP.
  • Сложная аналитика и отчёты. На старте хватает базовых событий.
  • Локализация. Один язык; каждый следующий — плюс треть работы по экранам.
  • AI «чтобы было». Если задачу решает простое правило — на MVP берём правило. Про экономику моделей — отдельный разбор.
Всё вычеркнутое не исчезает — оно переезжает во вторую версию, которую вы будете делать уже с данными: кто пользуется, что нажимает, где отваливается.

06 · Когда шесть недель станут десятью

Честно о рисках. Срок растягивается почти всегда по одной из четырёх причин:

  1. Задержки с материалами и доступами. Ждём выгрузку каталога или доступ к учётной системе — неделя простоя. Самая частая причина, и она не техническая.
  2. Правки после демо, меняющие суть. Мелкие правки укладываются в спринт, «а давайте вообще по-другому» — нет.
  3. Интеграция с 1С или редким сервисом. Закладывайте неделю сверху, если учётная система нетиповая.
  4. Второй тип пользователя, всплывший в середине. Это не «ещё пара экранов», а вторая половина системы: свои права, свои данные, свой интерфейс.

Что до денег: простой MVP на одной платформе — 350–500 тыс ₽, версия с обеими платформами, своим бэкендом и админкой — 700–950 тыс ₽. Оплата по спринтам: платите за следующие две недели, видя результат предыдущих. Как формируется смета целиком — в разборе цен, прикинуть свою вилку можно в калькуляторе.

Хотите увидеть такой план под свою задачу — опишите идею. На бесплатном разборе распишем ваши шесть недель поимённо: что попадёт в MVP, что во вторую версию и где риск сдвига.

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

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

Что я вижу в процессе?
Демо в конце каждой недели: экраны в дизайне → кликабельный каркас → работающий сценарий на реальных данных → оплата и уведомления → сборка в сторе.

Сколько это стоит?
350–500 тыс ₽ за простой MVP на одной платформе, 700–950 тыс ₽ с обеими платформами, бэкендом и админкой. Оплата этапами по две недели.

Из-за чего срок вырастает?
Чаще всего из-за задержек с вашей стороны — доступы, материалы, согласования. Технические причины реже: нетиповая 1С или внезапный второй тип пользователя.