Коротко. MVP на Flutter обычно занимает 6–12 недель — от старта до публикации в сторах. Стандартное бизнес-приложение — 3–6 месяцев. Сложное или регулируемое (финтех, медицина, всё, что будет читать аудитор) — 6–12+ месяцев. Сильнее всего на эти числа влияет не скорость написания кода, а объём работ и то, как быстро принимаются решения на стороне клиента. Фазы к тому же перекрываются, поэтому календарный срок всегда короче суммы фаз — именно поэтому «сколько времени» и «сколько работы» — два разных вопроса.
Любое агентство отвечает на этот вопрос словами «зависит от проекта». Действительно зависит — но под такой ответ нельзя запланировать запуск. Ниже — те цифры, которые мы называем сами, что в них входит и из-за чего они сдвигаются.
Сколько занимает Flutter-приложение по уровням сложности?
Три уровня покрывают почти всё, что нас просят построить. Сроки — от старта до публикации в сторах, при согласованном объёме и нормальном доступе к тому, кто принимает решения.
| Уровень | Типичный срок | Пример состава | Команда | Главный фактор сроков |
|---|---|---|---|---|
| MVP — проверить идею | 6–12 недель | 5–8 ключевых функций, iOS + Android, Firebase или лёгкий REST-бэкенд, UI на библиотеке компонентов, базовая аналитика | 1–2 Flutter-разработчика, дизайнер part-time, ведущий инженер | Дисциплина объёма. Каждое «небольшое дополнение» — это неделя. |
| Стандартное бизнес-приложение | 3–6 месяцев | 15–20 функций, своя дизайн-система, кастомный бэкенд, админ-панель, сегментированные пуши, офлайн, платежи | 2–3 Flutter-разработчика, бэкендер, дизайнер, QA | Интеграции и готовность бэкенда — обычно не само приложение |
| Сложное или регулируемое | 6–12+ месяцев | Compliance (HIPAA, PCI-DSS, SOC 2), ролевой доступ, данные в реальном времени, интеграции с ERP/CRM, ML на устройстве | Полная команда плюс DevOps и менеджер проекта | Зависимости, которыми вы не управляете: аудиторы, банки, вендоры |
Типичное бизнес-приложение — это три-пять месяцев; шестой появляется, когда интеграции или compliance приходят поздно, а приходят они поздно часто. Уровни совпадают с ценовыми в статье сколько стоит разработка Flutter-приложения в 2026 — примерно 1,4–2,7 млн ₽ за MVP и 2,7–5,4 млн ₽ за бизнес-приложение. Срок и бюджет двигаются вместе: вы покупаете команду на определённое число недель.
Куда уходят недели?
Здесь важнее всего третья колонка: эти фазы не идут одна за другой.
| Фаза | Типичный срок | Пересекается с |
|---|---|---|
| Дискавери и оценка объёма | 3 дня – 2 недели | Ничего реального не начинается раньше |
| UX/UI-дизайн | 2–4 недели | Стартует до конца дискавери, хвостом заходит в разработку |
| Архитектура и фундамент | 1–2 недели | Дизайн |
| Основная разработка | 4–16 недель | Хвост дизайна, QA, работа над бэкендом |
| Интеграции | 1–2 недели на каждую крупную | Основная разработка |
| QA и тестирование | Непрерывно плюс 1–2 недели стабилизации | Основная разработка |
| Сабмит и ревью в сторах | 1–2 недели (само ревью обычно 24–48 часов) | Идёт последним, ассеты готовятся заранее |
Сложите строки в лоб — получите восемь месяцев на проект, который выходит за четыре. Разницу даёт перекрытие: дизайн доделывает экраны, пока разработчики собирают уже согласованные, QA идёт внутри каждого спринта, а бэкенд нагрузочно тестируется против мока. Что именно происходит внутри каждой фазы — в парном материале про процесс разработки Flutter-приложения: эта статья про сколько времени, та — про как.
Сколько занимает MVP против полноценного продукта?
MVP занимает 6–12 недель, потому что MVP — это вопрос, а не продукт: 5–8 функций, UI на библиотеке компонентов, бэкенд, который вы не писали с нуля, и список отсечённого, который вы действительно соблюдаете.
Шесть недель — реальный срок, но с условиями. Нужен объём, который влезает на одну страницу, один человек, способный утвердить решение без комитета, и никакого нового технического риска: ни видеопайплайна, ни ML на устройстве, ни платёжных рельсов в новой юрисдикции. Перенос Telegram-бота с существующей аудиторией в нативное приложение занял шесть недель именно потому, что бот уже проверил продукт, а объём был зафиксирован.
Десять-двенадцать недель встречаются чаще, и лишний месяц почти никогда не про «код оказался сложнее» — это платёжный флоу, появившийся на четвёртой неделе, незапланированный раунд дизайна или две недели ожидания доступа к API.
Полноценный продукт занимает 3–6 месяцев по причине, не связанной с числом функций: он строится, чтобы выдержать реальную нагрузку пользователей — своя дизайн-система, настоящая бизнес-логика, офлайн-поведение, названные состояния ошибок, тесты в CI, админка для тех, кто отвечает на обращения. Это и есть та работа, которая отличает приложение, которое можно развивать, от того, которое переписывают через полтора года.
Что на самом деле определяет сроки?
Шесть вещей, примерно в порядке причиняемого ущерба.
1. Объём. С большим отрывом. «Простое приложение» превращается в 40 экранов, как только посчитаны онбординг, авторизация, настройки, удаление аккаунта, платежи, пуши и офлайн — а всё это всегда было в том приложении, которое вы описали. Две дополнительные функции добавляют не две недели кода, а код, дизайн, QA и новый набор пограничных случаев.
2. Готовность бэкенда. Если API существует, задокументирован и стабилен, Flutter-команда идёт на полной скорости. Если его параллельно пишет другая команда, ваш срок теперь равен их сроку.
3. Интеграции. Каждая значимая — платежи, карты, чат, видео, биометрия, CRM — это одна-две недели. SDK подключается за вечер; пограничные случаи занимают остальные две недели.
4. Зрелость дизайна. Приходить со своей дизайн-системой — это минус две-три недели, потому что разработчики собирают экраны из уже существующих компонентов. Отсутствие дизайна не ускоряет: работа просто переезжает в разработку, где стоит дороже.
5. Ревью в сторах. Одна-две недели на фазу сабмита, и большая часть этого времени — ваша работа, а не Apple. Подробнее ниже.
6. Скорость решений — обычно это вы. В проекте десятки открытых вопросов, и каждый ждёт кого-то. Десять вопросов с ответом на четвёртый день вместо первого добавляют шесть недель к проекту, в котором никто не написал ни одной медленной строчки. На здоровом проекте клиент — самое частое узкое место. И самое дешёвое в устранении.
Flutter действительно быстрее нативной разработки?
Да — но нужно точно понимать, что именно экономится, потому что здесь агентства обычно перегибают.
Flutter сокращает трудозатраты примерно на 30–40 % по сравнению с двумя нативными приложениями, и разрыв растёт по мере жизни продукта, потому что каждая следующая функция пишется один раз, а не два. Откуда берётся это число, мы разбирали в статье Flutter против нативной разработки в 2026.
Чего Flutter не делает — так это не сокращает календарь вдвое. Дискавери не становится короче от выбора Flutter, дизайн делается один раз в любом случае, QA всё равно нужны реальные устройства на обеих платформах, а бэкенду безразлично, на чём написан клиент. Шестимесячный нативный проект превращается примерно в четырёхмесячный на Flutter — не в трёхмесячный, — но с одной командой вместо двух и одной кодовой базой в поддержке.
Flutter — это способ получить две платформы почти по цене одной. Это не способ получить полугодовое приложение за шесть недель.
Сколько времени добавляет ревью в App Store и Google Play?
Заложите одну-две недели на всю фазу сабмита — и почти никогда не ошибётесь. Само ревью здесь — меньшая часть.
Ревью Apple обычно занимает 24–48 часов после отправки. «Обычно» не значит «гарантированно», но причины отказов достаточно предсказуемы, чтобы проектировать с их учётом: нет удаления аккаунта, экран входа без демо-доступа, неполная декларация приватности, платежи в обход внутренних покупок. Google проверяет как правило быстрее, но совсем новый аккаунт разработчика может застрять в расширенном ревью на несколько дней.
Время реально теряется на цикле отказа — это цикл длиной 24–72 часа, и первый сабмит, который его получает, — норма. Заложите один реджект, и вы его переварите; не заложите — и он придётся на дату запуска.
Дольше идут два случая: регулируемые данные вызывают у ревью дополнительные вопросы, а выпуск нескольких брендированных приложений из одной кодовой базы превращает гайдлайн Apple 4.2.6 в отдельную дисциплину — те же экраны с новым логотипом отклоняют как дубликаты. Мы описывали, что реально проходит ревью на масштабе; учесть это заранее — разница между недельным сабмитом и месяцем апелляций.
Где сроки поедут?
Почти все переработки срока, которые мы видели, объясняются четырьмя сценариями.
Расползание объёма мелкими просьбами. Ни одно отдельное «а можно ещё…» не выглядит неразумным. Шесть таких — это месяц.
API, который приходит поздно. Самая частая причина простоя Flutter-команды. Моки покупают пару недель, дальше не покупают ничего.
Дизайн через круги согласований. Три раунда «давайте посмотрим ещё один вариант» на главном экране задерживают все последующие фазы: разработчики не могут собирать против движущейся цели.
Нерешительность, включая молчание. Спринт, сборку которого никто на стороне клиента не поставил на телефон, — это спринт, чьи недопонимания вскроются через месяц.
Три из четырёх пунктов — на стороне клиента. Это не перевод ответственности, а указание на рычаг: агентство может ускорить разработку процентов на десять, решительный клиент сжимает календарь на тридцать.
Чек-лист: как выйти быстрее
Шесть рычагов, и все они в ваших руках:
- Зафиксируйте объём письменно и ведите список отсечённого. Функции, которые явно не входят в первую версию, — самый ценный артефакт проекта.
- Назначьте одного человека, принимающего решения — того, кто может утвердить дизайн или закрыть вопрос в тот же день.
- Приносите API — или примите, что он на критическом пути. Если бэкенд пишется параллельно, договоритесь об интерфейсе заранее и заморозьте его.
- Приходите с дизайн-системой — палитра, типографическая шкала, состояния компонентов — или заложите три недели на её создание. Пропустить не получится, расход просто переедет.
- Завести аккаунты в сторах, декларации приватности и демо-доступы нужно на первой неделе, а не на той, когда вы сабмитите.
- Добавляйте мощность, а не давление — и добавляйте заранее. Модели разобраны в статье как нанимать Flutter-разработчиков в 2026, а усиление команды — это как мы подключаем инженеров к существующей команде за дни, а не за месяцы.
Один антирычаг: разработчики, добавленные в последний месяц, делают проект медленнее, а не быстрее — они изучают код у тех, кто и так был узким местом.
Частые вопросы
Нужен срок под ваше приложение?
Общие диапазоны годятся, чтобы спланировать квартал, и бесполезны, чтобы спланировать запуск. Нужна цифра под ваш состав функций, состояние бэкенда и ограничения сторов.
Пришлите, что вы строите, — вернёмся с разобранным по фазам сроком: что идёт параллельно, что мы бы отрезали, чтобы попасть в дату, и какие части оценки зависят от вас, а не от нас. Если дата недостижима, мы скажем это до того, как вы что-то подпишете.
Это и есть наша практика разработки приложений на Flutter: фиксированный объём, устанавливаемая сборка каждые одну-две недели и срок, который мы готовы защищать, — посмотрите ExtraETF, рыночные данные в реальном времени в регулируемой сфере, и Arcana, AI-чат, доведённый до сторов.
Расскажите, что вы строите — и мы назовём дату, а не диапазон, в котором удобно спрятаться.
Дима — ведущий Flutter-разработчик Nerdy Production, Flutter-first агентства, которое доводит приложения от дискавери до App Store в финтехе, ритейле и AI-продуктах.