TL;DR.
- Закладывайте примерно 15–25% от стоимости разработки Flutter-приложения в год на поддержку — приложение за 2,7 млн ₽ обходится примерно в 405–675 тыс. ₽ в год, чтобы оставаться в порядке.
- Поддержка делится на четыре категории: исправление багов (корректирующая), реакция на изменения ОС/SDK/API (адаптивная), улучшение того, что уже работает (совершенствующая), и погашение технического долга до того, как он аукнется (превентивная).
- Flutter — это один поток поддержки, а не два: одна кодовая база для обновлений, тестирования и релизов вместо отдельных команд под iOS и Android, которые делают ту же работу дважды.
- Дешёвая разработка не гарантирует дешёвую поддержку: наспех написанный или бесконтрольно сгенерированный ИИ-код без тестов и архитектуры раздувает расходы сразу по всем четырём категориям.
- Поддержка — это процент, который начисляется каждый год, пока приложение живёт: закладывайте его в бюджет на старте, а не после первого инцидента.
Что на самом деле входит в понятие «поддержка»
«Поддержка» — расплывчатый термин для всего, что происходит после запуска, и именно поэтому её легко недооценить при планировании бюджета. Это не самодеятельная классификация: деление на четыре категории закреплено в ISO/IEC 14764, международном стандарте по сопровождению программного обеспечения, и на практике оно работает:
- Корректирующая — исправление багов, которые дошли до продакшена: краши, неверные расчёты, сломанные сценарии. Это первое, что приходит в голову при слове «поддержка», и обычно — самая небольшая категория в здоровой кодовой базе.
- Адаптивная — изменения, которые навязывает внешний мир: новый стабильный релиз Flutter, новая версия iOS или Android, обновление политики стора, платёжный провайдер меняет API. Вы не выбирали эту работу — её выбрала платформа.
- Совершенствующая — улучшения, которые никто не требует: оптимизация производительности, доработка UX, новые функции на существующих экранах. Именно здесь «поддержка» незаметно превращается в «развитие продукта» — и это нормально, просто это тоже текущие расходы.
- Превентивная — рефакторинг, обновление зависимостей, патчи безопасности и погашение технического долга до того, как что-то сломается, а не после. Это категория, которую первой урезают при сжатом бюджете, и та, что дороже всего аукается спустя пару лет.
Реалистичный годовой бюджет на поддержку должен покрывать все четыре категории, а не только корректирующую, о которой обычно думают в первую очередь основатели.
Сколько это стоит
Планируйте 15–25% от стоимости разработки в год. Где именно вы окажетесь в этом диапазоне, зависит от того, насколько активно приложение развивается новыми функциями (совершенствующая работа растёт вместе со скоростью продукта), сколько сторонних интеграций оно несёт (каждая — источник будущей адаптивной работы), и работаете ли вы в регулируемой сфере, где требования комплаенса меняются у вас на глазах.
Применим этот диапазон к уровням стоимости разработки из нашего разбора стоимости Flutter-разработки:
| Уровень | Типичная стоимость разработки | Типичная годовая поддержка |
|---|---|---|
| MVP | 1 350 000–2 700 000 ₽ | 202 500–675 000 ₽ |
| Бизнес-приложение | 2 700 000–5 400 000 ₽ | 405 000–1 350 000 ₽ |
| E-commerce | 4 500 000–8 100 000 ₽ | 675 000–2 025 000 ₽ |
| Enterprise / ИИ | от 8 100 000 ₽ | от 1 215 000 ₽ |
Эти цифры поддержки — то же самое правило, применённое к диапазонам стоимости разработки, а не отдельно посчитанная цифра: воспринимайте их как ориентир для планирования, а не как коммерческое предложение. Первый год после запуска обычно тянет к верхней границе диапазона: вы всё ещё находите корректирующие баги, которые всплывают у реальных пользователей и которые не поймало QA, а приложение ещё не стабилизировалось. Второй и третий год у качественно сделанного приложения обычно устаканиваются ближе к нижней границе. О том, как сама стоимость разработки раскладывается по фазам, — в нашем материале о процессе разработки Flutter-приложения и в разборе сроков — поддержка уже упомянута там как последняя фаза в обоих случаях.
Что формирует эту стоимость
Часть этих статей расходов касается любого приложения независимо от платформы. Часть — специфична именно для Flutter.
| Статья расходов | Специфично для Flutter? | Почему это стоит денег |
|---|---|---|
| Обновления Flutter SDK | Да | Flutter выпускает несколько стабильных релизов в год; оставаться в актуальной версии — дёшево, отстать на два мажорных релиза — уже нет. |
| Обновления iOS / Android и политика сторов | Нет | Apple и Google каждый год выпускают по мажорной версии ОС плюс минорные обновления, а требования сторов и API пересматривают по несколько раз в год. |
| Смена зависимостей / пакетов | Частично | Пакеты pub.dev забрасывают или в них прилетают breaking changes; нативные приложения несут тот же риск в своих собственных экосистемах пакетов. |
| Подписки на сторонние SDK | Нет | Аналитика, пуш-уведомления, платежи, карты — регулярные расходы на вендоров, не зависящие от фреймворка. |
| Бэкенд / хостинг / API | Нет | Растёт вместе с нагрузкой, а не с тем, на чём написан клиент. |
| Исправление багов (корректирующая) | Нет | В любом приложении есть баги; вопрос — сколько стоит найти и исправить каждый. |
| Патчи безопасности | Нет | И приложение, и его зависимости нужно патчить по мере появления уязвимостей. |
| Аналитика / мониторинг | Нет | Краш-репортинг и аналитика использования — это то, как вы находите проблемы раньше, чем это делают тикеты в поддержку. |
| Итерации по функциям (совершенствующая) | Нет | Самая крупная и переменная статья — растёт вместе с тем, насколько активно вы всё ещё строите продукт. |
Строки, специфичные для Flutter, — меньшая часть таблицы. Основная часть расходов после запуска не имеет никакого отношения к тому, на каком фреймворке написано приложение, — это цена эксплуатации софта как такового.
Где Flutter экономит (а где — нет)
Честная версия тезиса «Flutter дешевле поддерживать» у́же, чем маркетинговая: одна кодовая база — это один поток обновлений, один цикл QA и один релиз вместо двух. Команда, которая поддерживает iOS и Android раздельно, платит за одно и то же исправление бага, один и тот же апдейт SDK и один и тот же прогон регрессионного тестирования дважды — по разу на платформу, по разным графикам, часто силами двух разных инженеров, которым приходится синхронизироваться друг с другом. Это тот же самый механизм, что даёт Flutter примерно на 30–40% ниже стоимость разработки, чем у двух нативных приложений, — и по нашему собственному сравнению Flutter и нативной разработки, после запуска эта экономия обычно не уменьшается, а растёт: каждая следующая доработка и фикс по-прежнему пишутся один раз, а не дважды.
Где это работает не полностью: платформо-специфичные интеграции — глубокая работа с ARKit/ARCore, отдельные платёжные SDK, edge-кейсы фоновой обработки — всё равно требуют нативной экспертизы даже внутри Flutter-приложения, потому что в этот момент Flutter обращается к нативному коду, а не заменяет его. И Flutter-приложение несёт реальный риск зависимостей — так же, как нативное приложение зависит от своих библиотек: плагин может остаться без поддержки, или его вообще похоронит вендор, и его замена — это настоящая адаптивная работа. Flutter снижает, как часто вы платите за поддержку дважды, но не отменяет саму стоимость поддержки.
Почему плохо написанное приложение стоит дороже в поддержке
Каждая из четырёх категорий поддержки дорожает, если код под капотом плохой, — и «плохой» здесь не значит, что приложение выглядит сломанным для пользователя. Это значит: нет тестов — и каждый фикс рискует принести новую регрессию. Нет цельной архитектуры — и изменение на одном экране аукается побочными эффектами ещё на трёх, которые никто не предвидел. Задублированная логика — и один и тот же баг чинят один раз, а он всплывает где-то ещё через полгода.
Это не гипотеза. Мы проаудировали десятки написанных ИИ кодовых баз и почти всегда находили одни и те же шесть проблем: отсутствие тестов, задублированный код, отсутствие цельной архитектуры, callback hell вместо нормальных асинхронных паттернов, полное игнорирование среды деплоя и открытые секреты. Ничего из этого не видно в демо. Всё это всплывает, как только вы пытаетесь безопасно что-то изменить. Наш разбор Flutter-кода, написанного ИИ-агентами без присмотра, показывает ту же картину под другим углом — код, который сегодня работает и с каждым месяцем без ревью становится ощутимо сложнее трогать.
Практический вывод: MVP за 1,4 млн ₽, собранный на скорую руку и без единого ревью, — это не приложение с поддержкой за 202,5 тыс. ₽ в год. Это кандидат на переписывание, притворяющийся бюджетом на поддержку. Если вам досталась чужая кодовая база — написанная ИИ, отданная на аутсорс или любая другая — и вы не знаете, что именно унаследовали, для этого и существует аудит AI-кода: он покажет вашу реальную нагрузку по поддержке до того, как вы возьмёте на себя обязательства на год вперёд.
Кто занимается поддержкой
Три реальных варианта, те же компромиссы, что и при найме на изначальную разработку, — подробнее в нашем разборе in-house против агентства против team augmentation:
- In-house. Оправдано, когда приложение — ядро бизнеса и вы хотите постоянно владеть кодом и знаниями о нём. Самые высокие фиксированные расходы, лучшее долгосрочное владение.
- Ретейнер с агентством. Кто-то другой несёт бремя дежурств и Flutter/платформенной экспертизы; вы платите за используемую мощность. Минимум управленческой нагрузки, меньше контроля за тем, кто именно и когда трогает код.
- Team augmentation. Инженеры работают внутри вашей команды, вашего репозитория, вашего процесса — вы управляете роадмапом, они дают Flutter-мощность. Хорошо работает, когда у вас уже есть инженерный менеджмент, но не хватает рук, — через team augmentation.
Свою собственную постоянную поддержку мы ведём как почасовой ретейнер в месяц, привязанный к конкретному приложению, а не как фиксированный пакет — финтех-приложение с тремя платёжными SDK и контентное приложение без единой интеграции не должны попадать в один и тот же план поддержки, и мы лучше оценим объём точно, чем продадим вам цифру, которая не подходит вашему приложению.
Как снизить стоимость поддержки
Ничего экзотического — в основном это дисциплина, которую дёшево соблюдать и дорого игнорировать:
- Обновляйте зависимости каждый квартал, а не раз в два года. Один апдейт Flutter — это день работы. Три года отложенных апдейтов разом — это проект.
- Вкладывайтесь в тесты и CI на раннем этапе. Регрессия, пойманная в CI, стоит минуты. Та же регрессия, пойманная пользователем, стоит тикета в поддержку, хотфикса и доверия.
- Закладывайте превентивную работу отдельной строкой, а не тем, что остаётся после того, как выкатили функции. Это категория, которую первой урезают и которая дороже всего аукается, если её пропустить.
- Настороженно относитесь к хрупким или слабо поддерживаемым сторонним SDK. Каждый добавленный — это будущий источник адаптивной работы вне вашего контроля: проверяйте активность поддержки пакета до того, как начнёте от него зависеть, а не после того, как он сломается.
- Мониторьте раньше, чем об этом сообщат пользователи. Краш-репортинг и аналитика превращают тихий сбой в исправимый — ещё до того, как он станет отзывом в сторе.
Частые вопросы
Закладывайте примерно 15–25% от стоимости разработки приложения в год. Например, для приложения, которое стоило 2,7 млн ₽ в разработке, поддержка обходится примерно в 405–675 тыс. ₽ в год — сюда входят исправление багов, обновления ОС и SDK, патчи безопасности, хостинг и текущие улучшения.
Подберём план поддержки под ваше приложение
Самый быстрый способ получить реальную цифру — не правило большого пальца, а взгляд на вашу настоящую кодовую базу. Если у вас уже есть живое Flutter-приложение и вы хотите знать, во сколько реально обойдётся его поддержка, — мы оценим план поддержки под него. Если не уверены, что именно унаследовали, начните с аудита AI-кода — мы честно скажем, в каком оно состоянии. А если вы ещё на этапе разработки, наша команда разработки приложений на Flutter строит с расчётом на следующие три года, а не только на дату запуска. Свяжитесь с нами и расскажите, в какой точке сейчас находится ваше приложение.
Илья Никсан — основатель и ведущий разработчик Nerdy Production, Flutter-first агентства, которая строит и поддерживает приложения в финтехе, здравоохранении и ритейле.