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

на Flutter обычно занимает два-три месяца от старта до публикации в сторах и стоит 1,4–2,7 млн ₽. Обе цифры — из нашего гайда по стоимости, а на что именно уходят эти месяцы, поэтапно разобрано в разборе сроков: мы лучше опубликуем их и будем спорить по существу, чем начнём разговор с «зависит от многого».

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

Что входит в MVP

  • 5–8 ключевых функций — те, от которых зависит ответ, и никаких других
  • iOS и Android — одна кодовая база, одна команда
  • Managed-бэкенд вместо написанного с нуля, если только продукт не требует обратного
  • Интерфейс на библиотечных компонентах — Material и Cupertino, стилизованные, а не перерисованные, чтобы дизайн не был на критическом пути
  • Аналитика и сбор крэш-репортов с первого дня: MVP без телеметрии не отвечает ни на один вопрос
  • Публикация в обоих сторах, в которой подача считается этапом, а не кнопкой

Кто будет делать ваш MVP

Две вещи отличают команду, способную выпустить MVP, от команды, которая делает приложения.

Полноценный продукт, спроектированный и выпущенный за семь недель

OneTwoDo — двусторонний маркетплейс локальных услуг для Perform Connect Studios S.L.: объявления об уборке, ремонте, сантехнике и прочем, которые публикуют и просматривают люди в одном районе. Мы сделали продукт целиком: продуктовый дизайн, Flutter-клиент и всё, на чём это работает. Семь недель.

Он здесь из-за того, как был устроен объём. Двусторонний маркетплейс обычно сначала подразумевает бэкенд-команду и только потом всё остальное — аккаунты, сессии, база объявлений, хранилище фотографий, сервер под всем этим, — и именно туда обычно уходят первые три месяца небольшой команды. OneTwoDo вышел без единой строки этого слоя: Firebase Authentication для аккаунтов, Firestore для объявлений и профилей, Cloud Storage для фотографий, Analytics и Crashlytics вместо дашбордов, которые иначе пришлось бы строить. Ничего не нужно поднимать, патчить и держать на дежурстве.

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

Мы публикуем цифры, а не говорим «зависит от многого»

Любое агентство отвечает на «сколько времени» и «сколько денег» вилкой такой ширины, что пользы от неё нет. Наши цифры опубликованы на этой странице и на странице разработки на Flutter, а поэтапный разбор — в статьях Сколько времени занимает разработка Flutter-приложения и Стоимость разработки Flutter-приложения в 2026 году. Если ваш проект в них не укладывается, мы скажем это на этапе оценки — единственном моменте, когда эта информация чего-то стоит.

Что мы ещё выпускали такого размера: Arcana, AI-компаньон для гаданий на таро, чей Flutter-клиент — стриминговый чат, держащий тысячи сообщений на 60fps, — занял три недели; и Telegram-бот с готовой аудиторией, превращённый в приложение в сторах за шесть недель; это сводный план по нашим работам, а не один клиентский проект, и он быстрый именно потому, что продуктовый вопрос уже был закрыт в другом месте.

Что на самом деле требует MVP

Шесть вещей определяют, выйдет ли MVP за три месяца или растянется втрое против того, на что его планировали.

Список вырезанного, которого вы действительно придерживаетесь

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

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

Объём, которого вы не видите

«Простое приложение для учёта тренировок» — это пять экранов у вас в голове. На практике это онбординг, аутентификация через email, Google и Apple — у каждого свои граничные случаи, — собственно функция, настройки, профиль, удаление аккаунта (требование обоих сторов) и платёжный сценарий, если продукт монетизируется. Ничего из этого не лишнее, и ничего из этого вы не имели в виду, когда описывали приложение.

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

Бэкенд, который не пришлось писать с нуля

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

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

Телеметрия, иначе MVP не отвечает ни на что

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

То, что мы отказываемся урезать

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

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

Публикация в сторах — это этап

Закладывайте одну-две недели. Само ревью обычно занимает 24–48 часов, а вот работа вокруг него — нет: карточки в сторах, скриншоты под каждый обязательный размер устройства, политика конфиденциальности и декларации о данных, которых теперь требуют оба стора, и путь удаления аккаунта, который Apple проверит. Команды, которые узнают об этом на последней неделе, опаздывают по причинам, никак не связанным с их приложением.

Почему Flutter для MVP

Честный аргумент за Flutter здесь:

ТребованиеКак это решает Flutter
Оба стора за один бюджетОдна кодовая база, примерно на 30–40% дешевле двух нативных разработок — самый сильный рычаг именно на масштабе MVP
Итерации на глазах у пользователейHot reload за доли секунды: правка оказывается на устройстве быстрее, чем стартует нативная пересборка
Дизайн не на критическом путиВиджеты Material и Cupertino держат интерфейс, пока собственная дизайн-система вам ещё не нужна
Одна команда для наймаFlutter-разработчики, а не iOS-команда плюс Android-команда плюс координация между ними
v2 без переписыванияКодовая база MVP и есть кодовая база продукта: то же приложение дорастает до полноценного бизнес-приложения, а не заменяется

Где нативная разработка всё ещё выигрывает: если проверяемый вопрос и есть платформенная возможность — глубокий сценарий на Apple Watch, продукт вокруг виджетов, что-то на API, существующем только на одной платформе, — то преимущество кроссплатформенности схлопывается, и честным ответом может быть нативная разработка. Мы скажем, когда это так. Общая страница услуги — разработка на Flutter.

Как мы работаем

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

Из прототипа в продакшен. Если у вас уже что-то работает — сборка в Cursor, Bolt или Lovable либо длинные выходные с AI-агентом, — продуктовый вопрос может быть частично закрыт, и работа тут другая: сначала аудит, потом закрытие разрыва между «работает в демо» и «безопасно перед живыми пользователями». Это аудит AI-кода, а пошаговый разбор — в статье Как довести AI-прототип до продакшена.

Staff augmentation. Наши инженеры входят в вашу команду, в ваш репозиторий и ваши спринты, под вашим управлением. Подходит, когда у вас уже есть инженерное руководство и нужны дополнительные Flutter-разработчики — см. расширение команды и наш гайд по найму Flutter-разработчиков, где честно сказано, когда не стоит брать нас.

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

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

Вопросы, которые чаще всего задают основатели, планирующие первый релиз на Flutter.

Минимально жизнеспособный продукт — это наименьшее приложение, способное ответить на конкретный вопрос бизнеса: будут ли этим пользоваться, будут ли платить, тот ли это сценарий, который людям нужен. Ударение здесь на «жизнеспособный», а не на «минимальный»: продукт должен быть достаточно хорош, чтобы реакция настоящего пользователя что-то значила, — поэтому MVP — это не прототип и не кликабельный макет. На практике это 5–8 ключевых функций, настоящий бэкенд, аналитика, привязанная к заданному вопросу, и живая карточка в сторах. Всё сверх этого — объём, за который вы платите дважды: чтобы построить и чтобы поддерживать, пока не удалите.
Два-три месяца от старта до публикации в сторах для MVP на Flutter сразу под iOS и Android. Нижняя граница в два месяца реальна, но условна: объём, помещающийся на одну страницу, один человек, принимающий решения без комитета, и отсутствие принципиально нового технического риска — видеопайплайна, машинного обучения на устройстве, платёжной инфраструктуры в новой юрисдикции. Три месяца встречаются чаще, и лишний месяц редко приходится на инженерию. Это платёжный сценарий, появившийся на четвёртой неделе, незапланированный раунд дизайна или две недели ожидания доступа к чужому API.
Наш MVP-уровень опубликован на этой странице и на странице разработки на Flutter, а не сообщается приватно по запросу, и покрывает 5–8 функций под iOS и Android с managed-бэкендом и интерфейсом на библиотечных компонентах. Цифру двигает в первую очередь объём, во вторую — интеграции: каждая значимая сторонняя интеграция — это одна-две недели, а невидимый объём из онбординга, аутентификации, настроек, удаления аккаунта и платежей примерно постоянен, поэтому в маленьком проекте он занимает большую долю, чем в крупном. Полный разбор того, что формирует цифру, — в нашем гайде по стоимости разработки на Flutter.
Внутри: функции, от которых зависит вопрос, один чистый путь через них, аналитика на тех моментах, которые дают ответ, и обязательная по закону обвязка, без которой нельзя выпускаться, — в 2026 году это в том числе удаление аккаунта. Снаружи: вторая роль пользователя, админка, которую полгода можно вести в таблице, собственная дизайн-система, офлайн-режим и любая функция, оправданная пользователем, которого вы ещё не встречали. Рабочая проверка — изменится ли то, что вы узнаете из запуска, если это убрать. Если нет — это v2, а записанный список вырезанного и есть результат этапа оценки, а не сноска к нему.
Нет, если это делалось как MVP, а не как прототип. Прототип одноразовый по замыслу; MVP — первая версия продукта, который вы намерены оставить, поэтому в нём должны быть границы модулей, позволяющие функциям расти, непрерывная интеграция с первой недели, тесты на путях, где ошибка стоит денег, и настоящие состояния ошибок. Это стоит дней, а не недель, и это разница между тем, чтобы v2 была развитием, и тем, чтобы она была стартом заново. Ради скорости мы режем функции, уникальность дизайна и инфраструктуру, которую можно арендовать, — но никогда структуру самого кода.
Да, и всё чаще проекты именно так и начинаются. Сборка в Cursor, Bolt или Lovable часто означает, что продуктовый вопрос уже частично закрыт, и это действительно ценно, — но разрыв между «работает в демо» и «безопасно перед живыми пользователями» конкретен и предсказуем: открытые ключи и отсутствующая авторизация, некэшированные вызовы API с многократным перерасходом, чувствительные данные, уходящие в логи или третьим сторонам. Правильный путь в этом случае — сначала аудит, потом работа по выпуску, а не пересборка, которая выбрасывает уже полученные знания.
Обычно да, и это самый сильный аргумент в пользу Flutter именно на этой стадии. MVP проверяет спрос, а не платформы, и вы редко знаете заранее, из какого стора придут первые настоящие пользователи, — так что релиз в один стор означает проверку идеи на аудитории одной платформы и догадки о втором. Поскольку одна кодовая база Flutter даёт оба приложения, дополнительные затраты на второй стор невелики, а это ровно тот размен, который нужен первому релизу. Исключение — продукт, чьё ядро есть платформенная возможность: там кроссплатформенная экономия не про это.

Поэтапный разбор сроков — в статье Сколько времени занимает разработка Flutter-приложения, а как выглядит полноценный продукт, спроектированный и выпущенный за семь недель, — в кейсе OneTwoDo.