Главная причина перерасхода бюджета — изменение требований после старта. Этот фактор встречался в 46% проектов с увеличением бюджета.
Бюджет
ИССЛЕДОВАНИЕ APPFOX
Почему разработка приложений и игр выходит за бюджет: исследование AppFox 2026
Исследование AppFox на основе анализа 184 проектов, 268 смет, 147 клиентских брифов и 96 проектных ретроспектив за период январь 2024 — июнь 2026.
184
проекта в выборке
46%
перерасходов из-за изменений
2026
AppFox Research
Разработка мобильного приложения или игры редко идёт строго по первоначальной смете, если требования меняются после старта, интеграции оказываются сложнее ожидаемого, техническое задание неполное, а новые функции добавляются уже в процессе производства.
AppFox проанализировала обезличенные данные по проектам разработки мобильных приложений, мобильных игр, Telegram Mini Apps, браузерных игр, VR/AR-проектов, промо-игр и цифровых продуктов для бизнеса, чтобы определить, почему проекты выходят за бюджет и какие факторы чаще всего приводят к дополнительным расходам.
Это исследование поможет заказчикам заранее увидеть риски, правильно сравнивать сметы подрядчиков, управлять объёмом работ и снижать вероятность перерасхода.
КРАТКО
1
3
5
7
9
2
4
6
8
10
Главные выводы исследования
Внешние интеграции увеличивали бюджет в среднем на 18%, если API был неполным, нестабильным или не имел тестового контура.
Игровые проекты с изменением механики после прототипа выходили за бюджет на 32% чаще, чем проекты с утверждённым GDD.
Недооценка backend и админ-панели была причиной перерасхода в 31% приложений для бизнеса и e-commerce.
Проекты с готовым MVP-скоупом реже выходили за бюджет, чем проекты, где список функций менялся во время разработки.
Проекты без формализованного технического задания выходили за бюджет на 37% чаще, чем проекты с утверждённым ТЗ.
Добавление новой платформы после старта увеличивало бюджет в среднем на 20%.
Изменение дизайна после утверждения UX/UI приводило к дополнительным расходам в 27% проектов.
Недооценка QA и тестирования приводила к увеличению бюджета в 24% проектов, особенно в играх, e-commerce, fintech и продуктах с несколькими ролями.
Самый высокий риск перерасхода наблюдался у проектов с несколькими платформами, backend, платежами, интеграциями, кастомным дизайном, игровым контентом или multiplayer.
Главные причины перерасхода бюджета
| Причина перерасхода | Доля проектов | Среднее увеличение | Где встречается чаще всего |
|---|---|---|---|
| Изменение требований после старта | 46% | +28% | Приложения, MVP, e-commerce, игры |
| Добавление новых функций | 42% | +24% | MVP, бизнес-приложения, Telegram Mini Apps |
| Неполное техническое задание | 39% | +22% | Все типы проектов |
| Новые интеграции | 34% | +18% | E-commerce, CRM, 1С, платежи |
| Недооценка backend | 31% | +21% | Бизнес-приложения, сервисы, online-игры |
| Изменение UX/UI-дизайна | 27% | +14% | Приложения, промо-проекты, e-commerce |
| Добавление платформ | 23% | +20% | iOS, Android, Web, PC, Telegram |
| Усложнение игровой механики | 29% | +32% | Игры, промо-игры, образовательные игры |
| Рост объёма арта и анимации | 26% | +25% | 2D/3D-игры, VR/AR, промо-игры |
| Недооценка QA | 24% | +12% | Игры, fintech, e-commerce, проекты с ролями |
| Новые требования безопасности | 18% | +16% | Fintech, медицина, HR, персональные данные |
| Изменение сроков / срочность | 17% | +15% | Проекты с фиксированной датой релиза |
| Неготовность контента | 16% | +10% | Игры, лендинги, e-commerce, обучение |
| Проблемы производительности | 15% | +18% | Игры, VR/AR, highload, online-сервисы |
| Поддержка после релиза | 14% | +9% | Продукты с активным развитием |
Методология
- Период анализа
- январь 2024 — май 2026
- Выборка
- 184 проекта, 268 смет, 312 КП и 147 брифов
Вошло в выборку
- MVP мобильных приложений
- приложения для бизнеса
- e-commerce приложения
- сервисные приложения
- приложения с backend и личным кабинетом
- мобильные 2D-игры
- мобильные 3D-игры
- браузерные игры
- Telegram Mini Apps
- промо-игры
- образовательные и детские игры
- VR/AR-проекты
- PC-игры
- проекты с геймификацией
- проекты с AI-функциями
- проекты с внешними интеграциями
- проекты с платежами
- проекты с админ-панелью
Не включалось
- проекты без стартовой сметы
- проекты без зафиксированного объёма работ
- внутренние экспериментальные разработки
- проекты, остановленные до начала основного этапа
- разовые микрозадачи без полного цикла
- проекты, по которым невозможно обезличить данные
- проекты, где увеличение бюджета было заранее предусмотрено как отдельная фаза
МЕТОДОЛОГИЯ
Методология исследования
Какие данные анализировались
Исследование AppFox основано на обезличенном анализе:
- 184 завершённых проектов
- 312 коммерческих предложений
- 147 клиентских брифов
- 126 технических заданий
- 96 проектных ретроспектив
- 214 change request-заявок
- 73 дополнительных соглашений
- 168 оценок на доработку
- 1 420 задач из таск-трекеров
- 89 заявок на поддержку после релиза
Период анализа: январь 2024 — июнь 2026.
Что считалось перерасходом бюджета
В исследовании перерасходом бюджета считалось увеличение стоимости проекта относительно первоначально согласованной сметы или утверждённого объёма работ.
Перерасход бюджета = фактический бюджет проекта − первоначально согласованный бюджет Перерасход, % = (фактический бюджет − первоначальный бюджет) / первоначальный бюджет × 100 Пример: первоначальный бюджет 3 000 000 ₽, фактический 3 900 000 ₽ → перерасход +900 000 ₽ (+30%)
Что не считалось перерасходом
| Ситуация | Почему не считалась перерасходом |
|---|---|
| Заранее запланированная вторая фаза | Это отдельный этап продукта |
| Пострелизное развитие | Это развитие после MVP или релиза |
| Поддержка по отдельному договору | Это эксплуатационные расходы |
| Новая версия продукта | Это новая фаза, а не перерасход первой |
| Дополнительная платформа, заказанная отдельно | Это расширение продукта |
| Маркетинг, ASO, реклама | Это не разработка |
| Покупка трафика | Не относится к производственной смете |
| Лицензии и серверы клиента | Часто оплачиваются отдельно |
Что считалось перерасходом
| Ситуация | Почему считалась перерасходом |
|---|---|
| Функции добавлены до релиза первой версии | Изменился скоуп проекта |
| Требования уточнены после старта | Первоначальная оценка стала неполной |
| Интеграция оказалась сложнее заявленной | Изменился фактический объём работ |
| UX/UI переделан после утверждения | Появились повторные работы |
| Backend потребовал дополнительной архитектуры | Первоначальная серверная логика была недооценена |
| QA выявил критические сценарии, не учтённые в ТЗ | Объём тестирования вырос |
| Добавилась новая пользовательская роль | Изменилась бизнес-логика продукта |
Как классифицировались причины перерасхода
| Категория | Что включалось |
|---|---|
| Scope creep | Добавление функций, сценариев, ролей |
| Неполное ТЗ | Отсутствие требований, неточные формулировки |
| Интеграции | CRM, 1С, платежи, карты, API, внешние сервисы |
| Backend | Серверная логика, данные, роли, статусы, безопасность |
| Дизайн | Переделка UX/UI, новые состояния, анимации |
| Платформы | Добавление iOS, Android, Web, PC, Telegram |
| Игровой контент | Уровни, персонажи, арт, анимации, баланс |
| QA | Увеличение тестовых сценариев, регресс, багфиксы |
| Безопасность | Аудит, шифрование, требования к данным |
| Срочность | Увеличение команды или параллельных работ |
| Контент | Тексты, изображения, модели, материалы |
| Производительность | Оптимизация, нагрузка, FPS, серверы |
АНАЛИЗ
Почему проекты выходят за бюджет
1. Изменение требований после старта
Изменение требований — самая частая причина роста бюджета. Проект начинается с одного набора функций, но в процессе появляются новые сценарии, роли, интеграции, экраны и ограничения.
Типичные примеры:
- добавить личный кабинет
- добавить новую роль пользователя
- добавить админ-панель
- добавить оплату
- добавить интеграцию с CRM
- добавить push-уведомления
- изменить сценарий регистрации
- добавить web-версию
- добавить Telegram Mini App
- добавить аналитику
- добавить дополнительные уровни в игре
- добавить multiplayer
- изменить механику игры
Как изменение требований влияет на бюджет
| Изменение | Что добавляется к работам |
|---|---|
| Новая функция | Аналитика, дизайн, разработка, QA |
| Новая роль | Права доступа, сценарии, интерфейсы, тесты |
| Новая интеграция | API, обработка ошибок, тестовая среда |
| Новая платформа | Адаптация, сборка, QA, публикация |
| Новая игровая механика | Геймдизайн, разработка, баланс, тестирование |
| Новый дизайн | UX/UI, frontend, состояния, проверка |
Вывод: если функция появляется после старта, она почти всегда стоит дороже, чем если бы была описана на этапе оценки. Команде приходится менять уже принятые решения, пересобирать план и иногда переделывать часть готовой логики.
2. Неполное техническое задание
ТЗ не гарантирует отсутствие изменений, но снижает неопределённость. Если техническое задание неполное, команда уточняет требования уже во время разработки. Это увеличивает бюджет, потому что решения принимаются позже, когда часть продукта уже создана.
Частые проблемы в ТЗ
| Проблема | Как влияет на бюджет |
|---|---|
| Не описаны пользовательские роли | Нужно заново проектировать права доступа |
| Не описаны ошибки и пустые состояния | Доработки появляются на этапе QA |
| Не описаны интеграции | API оцениваются слишком поверхностно |
| Нет требований к админ-панели | Управление контентом приходится добавлять позже |
| Нет требований к безопасности | Добавляются проверки и защита данных |
| Не описаны платежные сценарии | Возвраты, статусы и ошибки появляются позже |
| Нет требований к аналитике | События и отчёты добавляются после релиза |
| Не описаны игровые правила | Геймплей меняется уже в продакшене |
| Не определён MVP | В первую версию попадает слишком много функций |
Проекты с ТЗ и без ТЗ
| Показатель | Проекты с ТЗ | Проекты без ТЗ | Разница |
|---|---|---|---|
| Доля проектов с перерасходом | 28% | 65% | +37 п.п. |
| Медианный перерасход | 14% | 31% | +17 п.п. |
| Среднее число change request | 3 | 8 | +5 |
| Средний срок согласований | 4 дня | 9 дней | +5 дней |
| Количество правок после старта | 6 | 15 | +9 |
Вывод: ТЗ не делает проект бесплатным или мгновенным, но снижает вероятность дорогостоящих изменений после старта.
3. Новые интеграции
Интеграции часто недооценивают, потому что снаружи они выглядят как простое «подключить API». На практике интеграция требует анализа документации, тестовой среды, обработки ошибок, логирования, проверки данных и повторного тестирования.
Что усложняет интеграции
| Фактор | Как влияет |
|---|---|
| Нет документации API | Требуется исследование и ручное тестирование |
| API нестабильный | Возникают ошибки и повторные проверки |
| Нет тестового контура | Проверка идёт на боевых данных или откладывается |
| Сложные форматы данных | Нужна дополнительная обработка |
| Несколько внешних систем | Появляются зависимости между интеграциями |
| Нет ответственного на стороне клиента | Команда ждёт доступы и ответы |
| Ограничения безопасности | Добавляются проверки и согласования |
| Разные статусы в системах | Нужно проектировать синхронизацию |
Примеры интеграций, которые часто увеличивают бюджет
| Интеграция | Почему может быть сложной |
|---|---|
| CRM | Лиды, статусы, пользователи, права, ошибки синхронизации |
| 1С | Справочники, остатки, заказы, форматы обмена |
| Платежи | Статусы, возвраты, ошибки, безопасность |
| СБП | QR, подтверждения, статусы, банковская логика |
| Карты | Геокодинг, маршруты, лимиты API |
| SMS | Провайдеры, лимиты, антифрод |
| Push | Сегменты, события, сценарии |
| Аналитика | События, цели, отчёты, корректность данных |
| LMS | Обучение, прогресс, пользователи, роли |
| Игровые сервисы | Лидерборды, авторизация, облачные сохранения |
4. Недооценка backend
Backend часто остаётся невидимым для заказчика, потому что пользователь видит только интерфейс. Но именно backend отвечает за данные, роли, статусы, права доступа, интеграции, безопасность, платежи, аналитику и админ-панель.
Что входит в backend
| Блок | Примеры |
|---|---|
| Авторизация | Телефон, email, соцсети, Telegram, токены |
| Пользователи и роли | Клиент, админ, менеджер, курьер, партнёр |
| Данные | Профили, заказы, заявки, прогресс |
| Бизнес-логика | Статусы, правила, переходы, ограничения |
| Интеграции | CRM, 1С, платежи, карты, API |
| Админ-панель | CRUD, фильтры, роли, отчёты |
| Уведомления | Push, email, SMS, Telegram |
| Аналитика | События, логи, метрики |
| Безопасность | Права, шифрование, защита данных |
| Масштабирование | Производительность, нагрузка, очереди |
Когда backend увеличивает бюджет
| Ситуация | Причина роста бюджета |
|---|---|
| Добавляется несколько ролей | Усложняются права и сценарии |
| Появляются статусы и workflow | Нужно проектировать бизнес-логику |
| Нужна админ-панель | Требуется отдельный интерфейс управления |
| Нужны платежи | Добавляются транзакции, ошибки, возвраты |
| Нужна аналитика | Требуются события, отчёты, логи |
| Требуется высокая нагрузка | Нужна архитектура и оптимизация |
| Нужны уведомления | Добавляются сценарии отправки |
| Нужны внешние API | Увеличивается интеграционный контур |
5. Изменение дизайна после утверждения
Изменения в дизайне могут казаться небольшими, но они влияют на UX, UI, frontend, mobile-разработку и QA. Особенно дорогими становятся правки, которые появляются после начала разработки.
Какие изменения дизайна увеличивают бюджет
| Изменение | Почему увеличивает стоимость |
|---|---|
| Новый пользовательский сценарий | Нужно менять UX и логику |
| Новые состояния экранов | Требуется дизайн, верстка, QA |
| Сложные анимации | Увеличивают frontend и тестирование |
| Ребрендинг | Меняются компоненты и визуальная система |
| Новая дизайн-система | Требует разработки компонентов |
| Адаптация под новые устройства | Увеличивает проверку интерфейсов |
| Переделка UI после разработки | Нужно менять уже реализованные экраны |
| Изменение навигации | Затрагивает структуру продукта |
Вывод: дизайн дешевле менять до разработки. После старта frontend и mobile-разработки те же изменения становятся дороже.
6. Добавление платформ
Одна платформа почти всегда дешевле нескольких. Когда новая платформа добавляется после старта, это влияет не только на разработку, но и на дизайн, тестирование, сборки, публикацию и поддержку.
Как платформы влияют на бюджет
| Добавленная платформа | Что добавляется |
|---|---|
| iOS | Разработка, сборка, QA, публикация |
| Android | Разработка, устройства, QA, публикация |
| Web | Адаптация интерфейса, frontend, браузерное тестирование |
| Telegram Mini App | Web-интерфейс, бот, авторизация, backend |
| PC | Управление, сборки, оптимизация, публикация |
| VR/AR | 3D, устройства, интерактив, тестирование |
| WebGL | Оптимизация, браузеры, производительность |
Влияние добавления платформ
| Требование | Среднее увеличение бюджета |
|---|---|
| Вторая mobile-платформа при native-разработке | +28% |
| Вторая mobile-платформа при кроссплатформе | +16% |
| Добавление web-версии | +22% |
| Добавление Telegram Mini App | +18% |
| Добавление PC-версии игры | +34% |
| Добавление VR/AR-версии | +41% |
ИГРЫ
Почему игровые проекты выходят за бюджет
Игры отличаются от обычных приложений тем, что в них стоимость зависит не только от функций, но и от контента, механик, баланса, арта, анимаций, оптимизации и тестирования.
Частые причины перерасхода в играх
| Причина | Как влияет на бюджет |
|---|---|
| Изменение core gameplay | Переделывается основная механика |
| Увеличение количества уровней | Добавляется контент, баланс и QA |
| Рост объёма арта | Нужны новые персонажи, окружение, UI |
| Добавление 3D | Требуются модели, текстуры, анимации |
| Добавление multiplayer | Нужны серверы, синхронизация, античит |
| Изменение монетизации | Требуется экономика, аналитика, интеграции |
| Недооценка баланса | Появляются дополнительные итерации |
| Недооценка QA | Нужно больше тестов и исправлений |
| Оптимизация под устройства | Требуется доработка производительности |
| Live ops | Добавляются события, обновления, поддержка |
Игровые проекты: GDD и перерасход
| Показатель | Проекты с GDD | Проекты без GDD | Разница |
|---|---|---|---|
| Доля проектов с перерасходом | 34% | 66% | +32 п.п. |
| Медианный перерасход | 16% | 38% | +22 п.п. |
| Количество изменений механик | 2 | 6 | +4 |
| Количество итераций баланса | 3 | 8 | +5 |
| Средний срок до релиза | 18 недель | 27 недель | +9 недель |
Вывод: GDD не устраняет все изменения, но снижает риск переделки основной игровой логики.
РИСКИ
Как тип проекта влияет на риск перерасхода
| Тип проекта | Риск | Медиана | Главные причины |
|---|---|---|---|
| Простое MVP | низкий / средний | 14% | Добавление функций, отсутствие приоритетов |
| Приложение для бизнеса | средний | 21% | Роли, backend, админ-панель |
| E-commerce | средний / высокий | 26% | Каталог, оплата, CRM, 1С |
| Сервисное приложение | средний | 20% | Статусы, уведомления, роли |
| Приложение с AI | высокий | 34% | R&D, данные, безопасность |
| Telegram Mini App | низкий / средний | 17% | Backend, бот, платежи, роли |
| Промо-игра | средний | 24% | Сроки, брендовые правки, аналитика |
| Мобильная 2D-игра | средний | 23% | Арт, уровни, баланс |
| Мобильная 3D-игра | высокий | 37% | 3D, оптимизация, QA |
| Online-игра | высокий | 39% | Backend, multiplayer, нагрузка |
| VR/AR-проект | высокий | 35% | 3D, устройства, производительность |
| PC-игра | средний / высокий | 31% | Контент, оптимизация, публикация |
ЭТАПЫ
На каком этапе чаще всего растёт бюджет
Приложения
| Этап | Почему бюджет растёт |
|---|---|
| Аналитика | Выясняется, что функций больше, чем в брифе |
| ТЗ | Появляются новые роли, сценарии и ограничения |
| UX/UI | Добавляются состояния, экраны, сценарии |
| Разработка | Обнаруживаются технические зависимости |
| Backend | Логика и интеграции оказываются сложнее |
| Интеграции | API работает иначе, чем ожидалось |
| QA | Выявляются неучтённые сценарии и ошибки |
| Публикация | Требуются доработки под правила стора |
| Поддержка | После релиза появляются новые требования |
Игры
| Этап | Почему бюджет растёт |
|---|---|
| Концепция | Меняется жанр или целевая аудитория |
| Геймдизайн | Усложняются правила и прогрессия |
| Прототип | Core gameplay требует переделки |
| Арт | Увеличивается объём ассетов |
| Разработка | Механики оказываются сложнее |
| Backend | Добавляется multiplayer или сохранения |
| Баланс | Нужно больше итераций |
| QA | Появляются баги на разных устройствах |
| Оптимизация | Требуется FPS, память, загрузка |
| Публикация | Нужны сборки, метаданные, исправления |
СМЕТЫ
Почему дешёвая смета часто становится дорогой
Низкая стартовая цена не всегда означает выгодное предложение. Иногда подрядчик считает только часть работ, а остальные блоки появляются после старта отдельными доплатами.
Что может быть не включено в дешёвую смету
| Не включено | Что произойдёт потом |
|---|---|
| Аналитика | Требования будут уточняться во время разработки |
| ТЗ | Появятся споры о составе работ |
| UX | Интерфейс придётся переделывать |
| UI-состояния | Ошибки, пустые состояния и адаптации добавят позже |
| Backend | Продукт будет только прототипом |
| Админ-панель | Контент придётся менять через разработчиков |
| Интеграции | Их оценят отдельной сметой |
| QA | Ошибки найдут пользователи |
| Публикация | Релиз может задержаться |
| Документация | Поддержка станет дороже |
| Передача исходников | Возникнет зависимость от подрядчика |
| Поддержка | После релиза всё станет отдельной оплатой |
Как проверять смету
| Вопрос | Почему важен |
|---|---|
| Что входит в цену? | Позволяет сравнить одинаковый объём работ |
| Есть ли аналитика? | Снижает риск ошибок в требованиях |
| Есть ли ТЗ? | Уменьшает неопределённость |
| Есть ли backend? | Без него многие функции невозможны |
| Есть ли админ-панель? | Без неё управление продуктом сложнее |
| Какие интеграции включены? | Интеграции часто дают рост бюджета |
| Сколько платформ включено? | Каждая платформа добавляет разработку и QA |
| Что считается правкой? | Влияет на доплаты |
| Что считается новой функцией? | Важно для управления scope creep |
| Сколько итераций дизайна включено? | Дизайн может сильно влиять на бюджет |
| Включено ли QA? | Без тестирования проект дешевле только на бумаге |
| Есть ли гарантийная поддержка? | После релиза почти всегда нужны исправления |
РЕКОМЕНДАЦИИ
Как снизить риск перерасхода
1. Зафиксировать MVP
MVP должен быть ограниченным, но жизнеспособным. Главная ошибка — включить в первую версию все возможные идеи.
Как разделить функции (MoSCoW)
| Категория | Что означает |
|---|---|
| Must-have | Без этого продукт не работает |
| Should-have | Важно, но можно отложить |
| Could-have | Желательно, но не критично |
| Won't-have now | Не входит в первую версию |
2. Подготовить ТЗ или подробный бриф
Минимально нужно описать:
- цель продукта
- целевую аудиторию
- платформы
- пользовательские роли
- основные сценарии
- список функций
- интеграции
- требования к дизайну
- требования к безопасности
- аналитику
- контент
- ограничения
- сроки
- критерии готовности
3. Проверить интеграции до старта
До начала разработки нужно получить: документацию API, тестовые доступы, описание форматов данных, список ограничений, ответственного на стороне внешней системы, тестовую среду, описание ошибок, требования к безопасности.
4. Утвердить дизайн до разработки
Нужно согласовать: UX-прототип, ключевые экраны, состояния интерфейса, пустые состояния, ошибки, мобильные адаптации, компоненты, дизайн-систему, анимации (если нужны).
5. Ввести change request-процесс
Любое изменение после старта должно проходить через понятную процедуру: запрос → описание → оценка влияния на бюджет → оценка влияния на сроки → решение → реализация.
Поля таблицы change request
| Поле | Что фиксировать |
|---|---|
| Что меняем | Новая функция, экран, интеграция, сценарий |
| Почему меняем | Бизнес-причина |
| На что влияет | Бюджет, сроки, команда, архитектура |
| Сколько стоит | Оценка в часах и деньгах |
| Когда реализуем | Сейчас или во второй фазе |
| Кто согласует | Ответственный со стороны заказчика |
| Статус | На оценке, согласовано, отклонено, перенесено |
ПРИЗНАКИ
Ранние признаки перерасхода
| Признак | Что означает |
|---|---|
| Функции добавляются каждую неделю | MVP не зафиксирован |
| Нет единого ответственного | Решения принимаются медленно |
| ТЗ меняется после старта | Оценка теряет точность |
| Интеграции не имеют доступов | Команда не может проверить API |
| Дизайн постоянно переделывается | Растут frontend и QA |
| Клиент не готовит контент | Часть работ блокируется |
| Backend описан слишком общо | Высокий риск недооценки |
| QA отложен на самый конец | Исправления будут дороже |
| В проект добавляются платформы | Растут разработка и тестирование |
| Нет буфера бюджета | Любая правка становится конфликтом |
ПЛАНИРОВАНИЕ
Как планировать бюджет
Рекомендуемая структура бюджета
| Блок | Рекомендуемый подход |
|---|---|
| Основная разработка | Оценивать по утверждённому скоупу |
| Буфер на изменения | Закладывать 10–35% в зависимости от сложности |
| Интеграции | Оценивать после проверки API |
| QA | Не сокращать ниже минимального уровня |
| Поддержка | Планировать отдельно после релиза |
| Вторая фаза | Не смешивать с MVP |
| Маркетинг | Считать отдельно от разработки |
| Серверы и лицензии | Выносить в эксплуатационные расходы |
Рекомендуемый буфер бюджета по типу проекта
| Тип проекта | Рекомендуемый буфер |
|---|---|
| Простое MVP | 10–15% |
| Приложение для бизнеса | 18–25% |
| E-commerce приложение | 20–30% |
| Telegram Mini App | 15–20% |
| Мобильная 2D-игра | 18–25% |
| Мобильная 3D-игра | 25–35% |
| Online-игра | 25–35% |
| VR/AR-проект | 25–35% |
| Проект с AI | 25–40% |
| Проект с 5+ интеграциями | 25–35% |
Буфер не означает, что подрядчик должен потратить эти деньги. Это резерв на управляемые изменения, которые часто появляются в цифровых продуктах.
ПРИМЕРЫ
Примеры перерасхода по типовым проектам
Пример 1. MVP мобильного приложения
Стартовый скоуп: авторизация, личный кабинет, заявки, push-уведомления, простая админ-панель.
| Изменение после старта | Влияние |
|---|---|
| Добавлена новая роль пользователя | +180 000 ₽ |
| Добавлены статусы заявок | +140 000 ₽ |
| Добавлена интеграция с CRM | +320 000 ₽ |
| Добавлены новые push-сценарии | +90 000 ₽ |
| Увеличен QA из-за новых сценариев | +110 000 ₽ |
| Итоговый перерасход | +28% |
Причина: первоначальный MVP не был зафиксирован, а часть бизнес-логики появилась уже во время разработки.
Пример 2. E-commerce приложение
Стартовый скоуп: каталог, карточка товара, корзина, оформление заказа, оплата, личный кабинет.
| Изменение после старта | Влияние |
|---|---|
| Добавлена интеграция с 1С | +520 000 ₽ |
| Добавлены остатки по складам | +260 000 ₽ |
| Добавлены промокоды | +190 000 ₽ |
| Добавлены возвраты платежей | +240 000 ₽ |
| Добавлена сложная админ-панель | +430 000 ₽ |
| Итоговый перерасход | +31% |
Пример 3. Промо-игра
Стартовый скоуп: простая 2D-игра, брендовый стиль, рейтинг, промокоды.
| Изменение после старта | Влияние |
|---|---|
| Изменена игровая механика | +260 000 ₽ |
| Добавлены новые уровни | +180 000 ₽ |
| Добавлена интеграция с CRM | +220 000 ₽ |
| Добавлена защита от накруток | +160 000 ₽ |
| Увеличен QA из-за рейтинга | +120 000 ₽ |
| Итоговый перерасход | +34% |
Пример 4. Мобильная 3D-игра
Стартовый скоуп: 3D-аркада с персонажем, несколькими уровнями, прогрессией и аналитикой.
| Изменение после старта | Влияние |
|---|---|
| Увеличено количество уровней | +650 000 ₽ |
| Добавлены новые персонажи | +480 000 ₽ |
| Добавлены анимации | +420 000 ₽ |
| Добавлена внутриигровая экономика | +360 000 ₽ |
| Потребовалась оптимизация FPS | +310 000 ₽ |
| Итоговый перерасход | +37% |
Причина: в 3D-играх бюджет растёт из-за контента, анимаций, оптимизации и дополнительного QA.
ОТВЕТСТВЕННОСТЬ
Кто влияет на бюджет проекта
Перерасход — это не только зона ответственности подрядчика. На бюджет влияют обе стороны: команда разработки и заказчик.
| Зона ответственности заказчика | Как влияет на бюджет |
|---|---|
| Быстро согласовывать решения | Снижает простой команды |
| Подготовить требования | Снижает неопределённость |
| Зафиксировать MVP | Уменьшает scope creep |
| Предоставить доступы | Ускоряет интеграции |
| Подготовить контент | Снижает задержки |
| Назначить ответственного | Ускоряет принятие решений |
| Не менять приоритеты без оценки | Сохраняет бюджетный контроль |
| Согласовывать change request | Делает изменения управляемыми |
| Зона ответственности подрядчика | Как влияет на бюджет |
|---|---|
| Прозрачно декомпозировать смету | Показывает состав работ |
| Выявлять риски до старта | Снижает неожиданности |
| Предлагать MVP-приоритеты | Помогает не раздувать первую версию |
| Оценивать интеграции отдельно | Не смешивает неизвестные API с базовой разработкой |
| Фиксировать изменения | Позволяет контролировать scope creep |
| Показывать влияние на сроки | Связывает бюджет с реальным планом работ |
ЧЕК-ЛИСТ
Чек-лист: как не выйти за бюджет
Перед стартом проекта проверьте:
- Есть утверждённый список функций
- Определён MVP
- Есть техническое задание
- Описаны пользовательские роли
- Описаны основные сценарии
- Описаны ошибки и нестандартные состояния
- Понятны интеграции
- Получены API-доступы
- Описаны требования к backend
- Нужна ли и описана ли админ-панель
- Описаны платежи
- Есть требования к безопасности
- Утверждены платформы
- Есть готовый дизайн или брендбук
- Известен объём контента
- Описаны игровые механики (если игра)
- Есть GDD (для игры)
- Согласованы критерии готовности
- Понятны условия правок
- Понятен процесс change request
- Заложен бюджетный буфер
- Определён ответственный за решения
ВЫВОДЫ
Выводы исследования
Главные выводы для заказчиков
Бюджет чаще всего растёт из-за изменения объёма работ
Если после старта добавляются функции, роли, платформы или интеграции, первоначальная смета перестаёт отражать реальный проект.ТЗ снижает риск перерасхода
Чем лучше описаны сценарии, роли, backend, интеграции и ограничения, тем точнее оценка.Интеграции нужно проверять до старта
API без документации, тестового контура и ответственного — один из главных источников дополнительных расходов.Backend нельзя оценивать поверхностно
В приложениях для бизнеса, e-commerce и online-играх серверная логика часто сложнее интерфейса.Игры выходят за бюджет из-за контента и итераций
Уровни, арт, анимации, баланс, оптимизация и multiplayer требуют отдельной оценки.Дешёвая смета может быть неполной
Нужно сравнивать не только итоговую цену, но и состав работ: аналитику, ТЗ, backend, QA, публикацию, документацию и поддержку.Change request-процесс помогает контролировать бюджет
Любое изменение после старта должно оцениваться по влиянию на стоимость, сроки и архитектуру.ГЛАВНЫЙ ВЫВОД
Перерасход бюджета возникает не потому, что «разработка стала дороже», а потому что изменился фактический объём работ. Чем больше проект отличается от первоначального описания — тем выше риск дополнительных затрат.ИНФОГРАФИКА
Ключевые данные
Данные основаны на обезличенной выборке AppFox и округлены для публикации
Медианная стоимость разработки по типам проектов
Диапазон мин – макс и медиана · данные исследования, тыс. ₽
MVP мобильного приложения
1500 тыс.
Приложение для бизнеса
3000 тыс.
E-commerce приложение
4000 тыс.
Мобильная 2D-игра
2500 тыс.
Telegram Mini App
700 тыс.
VR/AR-проект
3500 тыс.
0
5000
тыс. ₽
Диапазон (мин – макс) max-width: 1430px;
Медиана
· тыс. ₽
Распределение бюджета приложения по этапам
Типичные доли · данные исследования, %
Разработка 35%
Backend 20%
UX/UI дизайн 15%
QA 12%
Аналитика/ТЗ 8%
PM/DevOps 10%
Частые вопросы
Почему разработка приложения выходит за бюджет?
Чаще всего бюджет растёт из-за изменения требований после старта, добавления новых функций, неполного ТЗ, новых интеграций, недооценки backend, изменения дизайна, добавления платформ и увеличения объёма QA.
Почему разработка игры выходит за бюджет?
В играх бюджет чаще всего увеличивают изменение игровой механики, рост количества уровней, увеличение объёма арта, добавление multiplayer, внутриигровая экономика, балансировка, оптимизация и дополнительное тестирование.
Что такое scope creep?
Scope creep — это постепенное расширение объёма проекта после старта. Например, когда в MVP добавляют новые функции, роли, интеграции или платформы без пересмотра бюджета и сроков.
Можно ли полностью избежать перерасхода?
Полностью исключить изменения сложно, но можно снизить риск: подготовить ТЗ, зафиксировать MVP, проверить интеграции, утвердить дизайн, назначить ответственного за согласования и вести change request-процесс.
Почему ТЗ помогает удержать бюджет?
ТЗ фиксирует сценарии, роли, функции, интеграции, ограничения и критерии готовности. Чем меньше неопределённости, тем точнее оценка и ниже риск переделок.
Почему интеграции так часто увеличивают стоимость?
Интеграция требует не только подключения API, но и анализа документации, обработки ошибок, тестовой среды, логов, синхронизации данных и проверки реальных сценариев. Если API нестабилен или плохо описан, стоимость растёт.
Почему backend может стоить дороже, чем кажется?
Backend отвечает за данные, роли, статусы, права доступа, интеграции, платежи, безопасность, аналитику и админ-панель. Пользователь может видеть несколько экранов, но за ними часто находится сложная серверная логика.
Почему дешёвая смета может привести к перерасходу?
В дешёвой смете могут отсутствовать аналитика, ТЗ, backend, QA, интеграции, публикация, документация, поддержка или передача исходников. Эти работы появятся позже как дополнительные расходы.
Как понять, что смета неполная?
Проверьте, есть ли в смете аналитика, ТЗ, UX/UI, frontend, backend, интеграции, QA, публикация, PM, документация, гарантийная поддержка и условия изменения требований. Если блоков нет, цена может быть неполной.
Какой бюджетный буфер закладывать?
Размер буфера зависит от типа проекта. Для простых MVP он может быть меньше, для e-commerce, online-игр, VR/AR, AI-проектов и продуктов с большим количеством интеграций — выше. Рекомендуемый буфер AppFox для разных типов проектов — от 10% до 35%.
Как управлять изменениями после старта?
Любое изменение нужно оформлять как change request: описать задачу, оценить влияние на бюджет и сроки, согласовать решение и только потом запускать в работу.
ЦИТИРОВАНИЕ
Кратко для цитирования
Исследование AppFox основано на анализе 184 проектов, смет, технических заданий, клиентских брифов и проектных ретроспектив за период январь 2024 — июнь 2026.
- Главная причина перерасхода бюджета — изменение требований после старта, добавление новых функций и неполное ТЗ.
- Проекты без технического задания выходили за бюджет на 32 п.п. чаще.
- Внешние интеграции увеличивали бюджет в среднем на 18%.
- Добавление новой платформы после старта увеличивало бюджет в среднем на 20%.
- Игровые проекты чаще выходили за бюджет из-за изменения механик, роста объёма контента, арта, баланса и QA.
Источник: AppFox. Почему разработка приложений и игр выходит за бюджет: исследование AppFox на основе проектов, смет, технических заданий и ретроспектив. AppFox Research, 2026. URL: appfox.ru/research/pochemu-razrabotka-prilozheniy-i-igr-vyhodit-za-byudzhet-2026/
О ДОКУМЕНТЕ
Об исследовании
| Поле | Значение |
|---|---|
| Название | Почему разработка приложений и игр выходит за бюджет: исследование AppFox 2026 |
| Автор | AppFox Research |
| Период анализа | январь 2024 — июнь 2026 |
| Дата публикации | 15 июня 2026 |
| Дата обновления | 6 июля 2026 |
| Выборка | 184 проекта, 268 смет, 147 клиентских брифов и 96 проектных ретроспектив |
| Темы | перерасход бюджета, разработка приложений, разработка игр, MVP, ТЗ, backend, интеграции, QA, scope creep |
| Контакты для СМИ | info@appfox.ru |
ДИСКЛЕЙМЕР
Дисклеймер
Данные исследования отражают обезличенную статистику проектов, смет, технических заданий, клиентских брифов и проектных ретроспектив AppFox за указанный период. Перерасход конкретного проекта может отличаться от приведённых значений в зависимости от состава работ, платформ, дизайна, backend, интеграций, требований к безопасности, игровых механик, скорости согласований, команды и условий договора.
Материал не является публичной офертой. Для точной оценки бюджета и рисков проекта требуется анализ требований, пользовательских сценариев, технических ограничений, интеграций и бизнес-целей.
КАК ЦИТИРОВАТЬ ЭТО ИССЛЕДОВАНИЕ
info@appfox.ru
AppFox. Почему разработка приложений и игр выходит за бюджет: исследование AppFox на основе проектов, смет, технических заданий и ретроспектив. AppFox Research, 2026. URL: appfox.ru/research/pochemu-razrabotka-prilozheniy-i-igr-vyhodit-za-byudzhet-2026/
