Медианный срок разработки MVP мобильного приложения составил 12 недель.
Сроки
ИССЛЕДОВАНИЕ APPFOX
Сроки разработки мобильных приложений и игр в 2026 году
Исследование AppFox на основе анализа 184 проектов, смет, технических заданий, коммерческих предложений и клиентских брифов за период январь 2024 — июнь 2026.
184
проекта в выборке
12 недель
медианный срок MVP
10%
ускорение проектов с готовым ТЗ
Срок разработки мобильного приложения или игры зависит не только от количества экранов и функций. На календарь проекта влияют аналитика, техническое задание, дизайн, backend, интеграции, тестирование, согласования, публикация, готовность материалов, состав команды и количество изменений после старта.
AppFox проанализировала обезличенные данные по проектам разработки мобильных приложений, мобильных игр, Telegram Mini Apps, браузерных игр, VR/AR-проектов, промо-игр и цифровых продуктов для бизнеса, чтобы показать, сколько времени занимает разработка разных типов продуктов и какие факторы чаще всего увеличивают сроки.
Это исследование поможет заказчикам реалистично планировать запуск, оценивать предложения подрядчиков и понимать, почему проект нельзя точно оценить по срокам без анализа требований.
КРАТКО
1
3
5
7
9
2
4
6
8
10
Главные выводы исследования
Медианный срок разработки Telegram Mini App составил 6 недель.
Проекты с готовым техническим заданием запускались на 10% быстрее, чем проекты без формализованных требований.
Добавление второй платформы увеличивало срок проекта в среднем на 18% при нативной разработке и на 9% при кроссплатформенном подходе.
Игровые проекты с кастомным артом разрабатывались на 24% дольше, чем проекты с готовыми ассетами.
Медианный срок разработки мобильной игры составил 18 недель.
Медианный срок разработки VR/AR-проекта составил 16 недель.
Самый частый фактор задержки — изменение требований после старта проекта.
Проекты с внешними интеграциями занимали на 16% больше времени, чем проекты без интеграций.
Согласования со стороны заказчика занимали в среднем 14% календарного времени проекта.
Таблица: сколько времени занимает разработка приложений и игр
| Тип проекта | Нижний диапазон | Медианный срок | Верхний типичный диапазон | Что чаще всего увеличивает срок |
|---|---|---|---|---|
| MVP мобильного приложения | 8 недель | 12 недель | 4 месяца | Изменение требований, backend, интеграции |
| Приложение для бизнеса | 3 месяца | 5 месяцев | 8 месяцев | Роли, статусы, админ-панель, API |
| E-commerce приложение | 4 месяца | 6 месяцев | 10 месяцев | Каталог, оплата, склад, CRM / 1С |
| Сервисное приложение | 4 месяца | 6 месяцев | 9 месяцев | Несколько ролей, заявки, уведомления |
| Приложение с AI-функциями | 5 месяцев | 7 месяцев | 12 месяцев | R&D, данные, безопасность, интеграции |
| Мобильная 2D-игра | 10 недель | 4 месяца | 7 месяцев | Арт, уровни, баланс, QA |
| Мобильная 3D-игра | 4 месяца | 6 месяцев | 12 месяцев+ | 3D-модели, анимации, оптимизация |
| Промо-игра для бренда | 6 недель | 10 недель | 3 месяца | Срок кампании, брендовые согласования |
| Браузерная игра | 8 недель | 4 месяца | 8 месяцев | WebGL, оптимизация, аналитика |
| Telegram Mini App | 4 недели | 6 недель | 3 месяца | Backend, бот, платежи, роли |
| VR/AR-проект | 3 месяца | 4 месяца | 8 месяцев+ | 3D, устройства, трекинг, тестирование |
| PC-игра | 8 месяцев | 12 месяцев | 30 месяцев+ | Контент, уровни, оптимизация, Steam-релиз |
Методология
- Период анализа
- январь 2024 — июнь 2026
- Выборка
- 184 проекта, 268 смет, 312 КП и 147 брифов
Вошло в выборку
- MVP мобильных приложений
- приложения для бизнеса и e-commerce
- сервисные приложения
- мобильные 2D и 3D-игры
- браузерные игры
- Telegram Mini Apps
- промо-игры
- VR/AR-проекты
- PC-игры
- проекты с AI-функциями
Не включалось
- проекты без зафиксированной даты старта
- внутренние экспериментальные разработки
- разовые микрозадачи без полного цикла
- проекты только на поддержку
- проекты, остановленные заказчиком до завершения
МЕТОДОЛОГИЯ
Методология исследования
Какие данные анализировались
Исследование AppFox основано на обезличенном анализе:
- 184 завершённых проекта
- 312 коммерческих предложений
- 147 клиентских брифов
- 268 предварительных смет
- 96 технических заданий
- 121 проектный план
- 118 календарных графиков
- 73 ретроспективы после завершения проектов
- 129 заявок на доработку после релиза
Период анализа: январь 2024 — июнь 2026.
Что считается сроком разработки
В исследовании под сроком разработки понимается календарное время от фактического старта работ до первого релиза или передачи готовой версии заказчику.
В срок разработки включались
| Этап | Включался в расчёт |
|---|---|
| Старт проекта / kickoff | Да |
| Предпроектная аналитика | Да, если входила в проект |
| Техническое задание | Да |
| UX/UI-дизайн | Да |
| Геймдизайн | Да, для игровых проектов |
| Прототипирование | Да |
| Разработка приложения или игры | Да |
| Backend-разработка | Да |
| Интеграции | Да |
| Тестирование | Да |
| Исправление критических ошибок | Да |
| Подготовка к публикации | Да |
| Публикация / передача релизной версии | Да |
В срок разработки не включались
| Этап | Почему исключался |
|---|---|
| Переговоры до заключения договора | Это пресейл, а не производство |
| Юридическое согласование договора | Не относится к разработке |
| Ожидание оплаты | Не относится к производственному циклу |
| Маркетинговое продвижение после релиза | Это отдельный этап |
| Покупка трафика | Не относится к разработке |
| Долгосрочная поддержка после релиза | Считается отдельно |
| Развитие продукта после первой версии | Это следующий этап продукта |
Как считались значения
| Показатель | Что означает |
|---|---|
| Нижний диапазон | Самые быстрые проекты в категории после исключения выбросов |
| P25 | 25-й перцентиль: четверть проектов завершалась быстрее этого срока |
| P50 / медиана | Срединное значение: половина проектов быстрее, половина дольше |
| P75 | 75-й перцентиль: три четверти проектов завершались быстрее этого срока |
| Верхний типичный диапазон | Верхняя граница без экстремальных выбросов |
| Среднее значение | Среднеарифметическое, используется осторожно из-за долгих проектов |
| Доля этапа в сроке | Процент календарного времени на аналитику, дизайн, разработку, QA и согласования |
| Задержка | Отклонение фактического срока от планового |
В исследовании основной показатель — медиана, а не среднее значение. Среднее может искажаться крупными или замороженными проектами: один сложный VR-симулятор или корпоративное приложение с долгими согласованиями может быть значительно дольше типичного проекта.
СЦЕНАРИИ
Почему срок нельзя определить только по количеству экранов
Количество экранов важно, но оно не объясняет весь срок разработки. Два приложения с 20 экранами могут сильно отличаться:
| Проект | Почему сроки разные |
|---|---|
| Простое приложение с 20 статичными экранами | Быстрее, потому что мало логики и интеграций |
| Приложение с 20 экранами, ролями, оплатой, API и админкой | Дольше, потому что есть backend, сценарии, статусы, тестирование |
На срок влияют
- количество пользовательских ролей
- сложность backend
- наличие интеграций
- количество платформ
- требования к безопасности
- количество состояний интерфейса
- готовность дизайна
- готовность контента
- скорость согласований
- наличие технического задания
- необходимость прототипа
- уровень тестирования
- требования магазинов приложений
- качество исходных данных
Корректный вопрос звучит не как «Сколько времени занимает приложение на 20 экранов?», а как «Сколько времени занимает продукт с таким количеством сценариев, ролей, платформ, интеграций, backend-логики, дизайна, тестирования и требований к релизу?»
ПРИЛОЖЕНИЯ
Сколько времени занимает разработка мобильного приложения
Сроки по типам приложений
| Тип приложения | Что обычно входит | Нижний | Медиана | Верхний |
|---|---|---|---|---|
| Простое MVP | Авторизация, 5–8 экранов, базовый backend, публикация | 8 недель | 12 недель | 4 месяца |
| Приложение для бизнеса | Личный кабинет, роли, уведомления, админка | 3 месяца | 5 месяцев | 8 месяцев |
| E-commerce | Каталог, корзина, оплата, заказы, интеграции | 4 месяца | 6 месяцев | 10 месяцев |
| Сервисное приложение | Заявки, статусы, роли, backend, уведомления | 4 месяца | 6 месяцев | 9 месяцев |
| Приложение с AI | Чат-бот, рекомендации, персонализация, ML-интеграции | 5 месяцев | 7 месяцев | 12 месяцев |
| Финтех / KYC | Безопасность, платежи, идентификация, комплаенс | 6 месяцев | 8 месяцев | 14 месяцев |
| AR-приложение | 3D-модели, трекинг, интерактив, оптимизация | 3 месяца | 5 месяцев | 9 месяцев |
Типовой календарь MVP мобильного приложения
Ниже приведён пример календарного плана для MVP мобильного приложения. Реальный срок зависит от состава функций, платформ, backend и скорости согласований.
| Этап | Типичный срок |
|---|---|
| Kickoff и уточнение требований | 3–5 дней |
| Аналитика | 1–2 недели |
| Техническое задание | 1–2 недели |
| UX-прототип | 1–2 недели |
| UI-дизайн | 2–3 недели |
| Mobile-разработка | 4–8 недель |
| Backend-разработка | 3–6 недель |
| Интеграции | 1–3 недели |
| QA | 2–3 недели |
| Исправление критических ошибок | 1–2 недели |
| Подготовка к публикации | 3–7 дней |
| Первый релиз | 1–3 дня |
Важно: часть этапов может идти параллельно. Например, backend и mobile-разработка могут выполняться одновременно после утверждения API и архитектуры. Но аналитика, ключевые сценарии и UX обычно должны быть проработаны до активной разработки.
Почему MVP может занять дольше ожидаемого
MVP часто воспринимают как «быструю версию продукта». MVP начинает занимать больше времени, если:
- нет готового ТЗ
- функции постоянно добавляются после старта
- не определена целевая аудитория
- нет приоритетов по функциям
- backend сложнее, чем предполагалось
- нужно несколько пользовательских ролей
- нужны платежи или внешние API
- нет готового дизайна или брендбука
- заказчик долго согласовывает макеты
- требуется публикация сразу в нескольких сторах
- после тестирования обнаруживаются критические изменения в логике
Правильный MVP — это не сокращение всех этапов, а сокращение набора функций. Аналитика, архитектура, UX и тестирование всё равно нужны.
ИГРЫ
Сколько времени занимает разработка мобильной игры
Почему игры оцениваются иначе, чем приложения
У обычного приложения есть функциональные сценарии: зарегистрироваться, оформить заказ, оплатить, получить уведомление. У игры есть дополнительные производственные слои:
- core gameplay
- геймдизайн
- баланс
- уровни
- персонажи
- арт
- анимация
- звук
- туториал
- внутриигровая экономика
- монетизация
- оптимизация
- игровое тестирование
- live ops
Поэтому даже простая на первый взгляд игра может занять больше времени, чем бизнес-приложение с похожим количеством экранов.
Сроки разработки игр по типам
| Тип игры | Примеры | Нижний | Медиана | Верхний |
|---|---|---|---|---|
| Гиперказуальная мобильная игра | Кликер, раннер, простая аркада | 4 недели | 6 недель | 3 месяца |
| Казуальная 2D-игра | Пазл, match-3, викторина | 10 недель | 4 месяца | 7 месяцев |
| Промо-игра | Игра для бренда, акции, лендинга | 6 недель | 10 недель | 3 месяца |
| Образовательная игра | Обучение, дети, HR, тренажёр | 2 месяца | 4 месяца | 8 месяцев |
| 3D-игра | Симулятор, аркада, приключение | 4 месяца | 6 месяцев | 12 месяцев+ |
| Мобильная PvP-игра | Рейтинги, комнаты, matchmaking | 5 месяцев | 8 месяцев | 14 месяцев+ |
| RPG / midcore | Прогрессия, персонажи, инвентарь | 6 месяцев | 10 месяцев | 18 месяцев+ |
| MMORPG / сложная online-игра | Сервер, экономика, live ops | 9 месяцев | 14 месяцев+ | 24 месяца+ |
| PC-игра | Steam, desktop, itch.io | 4 месяца | 8 месяцев | 18 месяцев+ |
| VR/AR-игра | Обучение, тренажёр, выставка | 4 месяца | 7 месяцев | 12 месяцев+ |
Типовой календарь мобильной игры
| Этап | Типичный срок |
|---|---|
| Концепция | 3–7 дней |
| Геймдизайн | 1–3 недели |
| GDD | 1–2 недели |
| Прототип core gameplay | 2–4 недели |
| Арт-концепты | 1–3 недели |
| Производство 2D / 3D-ассетов | 3–10 недель |
| Разработка игровых механик | 4–12 недель |
| Backend, если нужен | 3–10 недель |
| Балансировка | 1–4 недели |
| Звук и эффекты | 1–3 недели |
| QA | 2–8 недель |
| Оптимизация | 1–4 недели |
| Подготовка к публикации | 3–10 дней |
| Первый релиз | 1–3 дня |
Что чаще всего задерживает игровые проекты
| Причина | Как влияет на срок |
|---|---|
| Непроверенная игровая механика | Требуется прототип и несколько итераций |
| Изменение жанра или core gameplay | Может затронуть весь проект |
| Увеличение количества уровней | Добавляет контент, баланс и QA |
| Уникальный арт-стиль | Требует больше концептов и согласований |
| 3D вместо 2D | Увеличивает моделирование, анимации и оптимизацию |
| Мультиплеер | Добавляет backend, синхронизацию, тестирование |
| Внутриигровая экономика | Требует расчётов и балансировки |
| Монетизация | Добавляет интеграции, аналитику и тестирование |
| Несколько платформ | Увеличивает сборки, QA и оптимизацию |
| Отсутствие готового контента | Команда ждёт тексты, уровни, звуки, материалы |
TELEGRAM
Сколько времени занимает Telegram Mini App
Telegram Mini App может быть быстрее классического мобильного приложения, потому что продукт работает внутри Telegram и не требует отдельной установки. Но это не означает, что такой проект всегда простой.
Срок зависит от наличия: backend; бота; платежей; админ-панели; ролей пользователей; интеграции с CRM; игровой механики; рейтингов; промокодов; аналитики; защиты от накруток; массовых уведомлений.
Сроки Telegram Mini Apps
| Тип Mini App | Примеры | Нижний | Медиана | Верхний |
|---|---|---|---|---|
| Простая Mini App | Квиз, форма, каталог | 3 недели | 6 недель | 8 недель |
| Mini App для продаж | Каталог, корзина, заказ | 6 недель | 10 недель | 5 месяцев |
| Игровая Mini App | Квест, промо-игра, рейтинг | 6 недель | 10 недель | 6 месяцев |
| Сервисная Mini App | Личный кабинет, заявки, статусы | 8 недель | 4 месяца | 7 месяцев |
| Сложная Mini App | Роли, платежи, интеграции, аналитика | 4 месяца | 6 месяцев | 9 месяцев |
Типовой календарь Telegram Mini App
| Этап | Типичный срок |
|---|---|
| Аналитика сценариев | 3–7 дней |
| UX/UI | 1–2 недели |
| Frontend-разработка | 2–5 недель |
| Backend | 2–6 недель |
| Интеграция с Telegram Bot API | 3–10 дней |
| Платежи, если нужны | 3–10 дней |
| Админ-панель | 1–3 недели |
| QA | 1–2 недели |
| Запуск | 1–3 дня |
Telegram Mini App быстрее запускать, если у заказчика уже есть понятные сценарии, тексты, брендовые материалы и готовые API. Если Mini App превращается в полноценный сервис с ролями, платежами, аналитикой и интеграциями, сроки становятся ближе к разработке web-приложения.
VR / AR
Сколько времени занимает VR/AR-проект
VR/AR-проекты требуют больше тестирования на устройствах, чем обычные интерфейсы. В таких проектах важно не только написать код, но и проверить, как пользователь взаимодействует с объектами в пространстве.
На сроки влияют: сложность 3D-моделей; количество интерактивных объектов; требования к точности трекинга; тип устройства; производительность; сценарии обучения или демонстрации; интеграции с внешними системами; тестирование на реальном оборудовании.
Сроки VR/AR-проектов
| Тип проекта | Примеры | Нижний | Медиана | Верхний |
|---|---|---|---|---|
| AR-маска / простой AR-эффект | Бренд, соцсети | 4 недели | 6 недель | 3 месяца |
| AR-каталог | Мебель, товары, примерка | 2 месяца | 4 месяца | 8 месяцев |
| VR-презентация | Выставка, шоурум | 3 месяца | 5 месяцев | 9 месяцев |
| VR-тренажёр | Обучение персонала | 4 месяца | 7 месяцев | 12 месяцев+ |
| Сложный VR/AR-продукт | Симулятор, промышленность, медицина | 6 месяцев | 10 месяцев+ | 18 месяцев+ |
Типовой календарь VR/AR-проекта
| Этап | Типичный срок |
|---|---|
| Аналитика сценария | 1–2 недели |
| Техническое задание | 1–2 недели |
| UX в пространстве | 1–3 недели |
| 3D-моделирование | 3–10 недель |
| Разработка интерактива | 4–12 недель |
| Оптимизация | 1–4 недели |
| Тестирование на устройстве | 1–4 недели |
| Исправления | 1–3 недели |
| Передача / публикация | 3–10 дней |
РАСПРЕДЕЛЕНИЕ
Как распределяется срок по этапам
Мобильные приложения
| Этап | Нижний диапазон | Медианная доля | Верхний диапазон |
|---|---|---|---|
| Аналитика и ТЗ | 8% | 12% | 18% |
| UX/UI-дизайн | 12% | 18% | 25% |
| Mobile-разработка | 28% | 36% | 48% |
| Backend | 12% | 18% | 28% |
| Интеграции | 5% | 10% | 20% |
| QA | 10% | 14% | 22% |
| Исправления | 4% | 7% | 12% |
| Согласования | 5% | 9% | 18% |
| Публикация | 2% | 4% | 8% |
В приложениях часть этапов можно выполнять параллельно, но не все. Например, разработку backend и frontend можно вести одновременно, если заранее согласована архитектура и API. Но нельзя качественно начать разработку ключевых сценариев, если они ещё не описаны.
Мобильные игры
| Этап | Нижний диапазон | Медианная доля | Верхний диапазон |
|---|---|---|---|
| Концепция и геймдизайн | 10% | 15% | 24% |
| GDD | 5% | 8% | 14% |
| Прототип | 6% | 10% | 18% |
| Арт | 12% | 20% | 32% |
| Анимация | 6% | 10% | 18% |
| Разработка механик | 22% | 32% | 44% |
| Backend | 8% | 14% | 25% |
| Балансировка | 6% | 10% | 18% |
| QA | 10% | 16% | 26% |
| Оптимизация | 5% | 8% | 16% |
| Публикация | 2% | 4% | 8% |
В играх тестирование и балансировка часто занимают больше времени, чем ожидает заказчик. Даже если игра технически работает, её нужно проверить на понятность, сложность, стабильность, производительность и повторное прохождение.
ФАКТОРЫ ПРИЛОЖЕНИЯ
Что сильнее всего увеличивает срок приложения
| Фактор | Как влияет на срок | Пример |
|---|---|---|
| Нет готового ТЗ | Команда тратит время на уточнения | Функции обсуждаются во время разработки |
| Много пользовательских ролей | Увеличивает логику и тестирование | Клиент, админ, менеджер, курьер |
| Несколько платформ | Увеличивает разработку и QA | iOS + Android + Web |
| Сложный backend | Добавляет архитектуру и серверную разработку | Заказы, статусы, права доступа |
| Внешние интеграции | Создают зависимость от сторонних API | CRM, 1С, платежи, карты |
| Платежи | Требуют тестирования ошибок и возвратов | Эквайринг, СБП, статусы |
| Безопасность | Увеличивает проектирование и QA | Финтех, медицина, персональные данные |
| Кастомный дизайн | Увеличивает UX/UI и frontend | Анимации, сложные состояния |
| Офлайн-режим | Усложняет архитектуру | Синхронизация после восстановления связи |
| Долгие согласования | Растягивают календарь | Макеты утверждаются неделями |
ФАКТОРЫ ИГРЫ
Что сильнее всего увеличивает срок игры
| Фактор | Как влияет на срок | Пример |
|---|---|---|
| Сложный core gameplay | Требует прототипирования | Механику нужно проверять до продакшена |
| 3D-графика | Увеличивает производство ассетов | Модели, текстуры, анимации |
| Мультиплеер | Добавляет backend и синхронизацию | Комнаты, matchmaking, задержки |
| Количество уровней | Увеличивает контент и QA | 10 уровней и 100 уровней — разные сроки |
| Уникальный арт | Требует больше концептов | Персонажи, окружение, UI |
| Внутриигровая экономика | Требует балансировки | Валюта, награды, прогрессия |
| Монетизация | Добавляет интеграции | Реклама, IAP, подписки |
| Несколько платформ | Увеличивает сборки и QA | Android, iOS, PC |
| Оптимизация | Требует тестов на устройствах | FPS, память, загрузка |
| Live ops | Требует пострелизной команды | Сезоны, события, обновления |
ТЕХНИЧЕСКОЕ ЗАДАНИЕ
Как наличие ТЗ влияет на сроки
Готовое техническое задание не всегда сокращает весь календарь проекта, потому что само ТЗ требует времени. Но оно снижает неопределённость, уменьшает количество переделок и ускоряет производственный этап.
Проекты с ТЗ и без ТЗ
| Показатель | Проекты с ТЗ | Проекты без ТЗ |
|---|---|---|
| Средний срок старта разработки | 5 дней | 12 дней |
| Средний срок до первого релиза | 12 недель | 16 недель |
| Количество изменений после старта | 3–5 | 9–14 |
| Доля проектов с задержкой | 24% | 47% |
| Среднее отклонение от плана | 8% | 22% |
| Средний срок согласования дизайна | 6 дней | 14 дней |
По данным AppFox, проекты без формализованного ТЗ чаще сталкиваются с изменениями требований после старта. Это влияет не только на сроки, но и на бюджет, приоритеты команды и качество итогового продукта.
СОГЛАСОВАНИЯ
Как согласования влияют на календарь
Срок разработки зависит не только от скорости команды. В проектах с заказной разработкой значительную часть календаря занимают согласования.
Согласовываются: пользовательские сценарии; техническое задание; прототипы; дизайн-макеты; тексты; брендовые материалы; API и доступы; тестовые сборки; список исправлений; релизная версия; публикация.
Влияние скорости согласований
| Среднее время ответа заказчика | Как влияет на проект |
|---|---|
| До 1 рабочего дня | Проект идёт близко к плану |
| 2–3 рабочих дня | Появляются небольшие календарные сдвиги |
| 4–7 рабочих дней | Этапы начинают простаивать |
| Более 7 рабочих дней | Проект может растянуться на недели или месяцы |
| Нерегулярная обратная связь | Возникают переделки и потеря контекста |
Если команда ждёт утверждения ключевого сценария или дизайна, параллельная работа не всегда возможна. Особенно это критично на ранних этапах: аналитике, UX и архитектуре.
ИНТЕГРАЦИИ
Почему интеграции увеличивают сроки
Интеграция — это не просто подключение API. В реальном проекте нужно: получить доступы; изучить документацию; проверить ограничения API; согласовать формат данных; обработать ошибки; настроить тестовую среду; проверить реальные сценарии; настроить логи; протестировать сбои; предусмотреть изменения внешнего сервиса.
Влияние количества интеграций
| Количество интеграций | Типичный эффект на срок |
|---|---|
| 0 интеграций | Проект идёт по базовому плану |
| 1–2 интеграции | Добавляется 5–10 дней |
| 3–5 интеграций | Добавляется 3–6 недель |
| Более 5 интеграций | Требуется отдельный интеграционный контур |
| Интеграции без документации | Высокий риск задержки |
| Интеграции с нестабильным API | Высокий риск повторного тестирования |
Особенно сильно сроки увеличиваются, если API сторонней системы не готов, документация устарела или тестовый контур отличается от боевого.
ПЛАТФОРМЫ
Как платформы влияют на сроки
Одна платформа почти всегда быстрее нескольких. Но эффект зависит от технологии.
Сравнение подходов
| Подход | Как влияет на сроки |
|---|---|
| Только iOS | Быстрее, если аудитория ограничена iOS |
| Только Android | Быстрее, если аудитория ограничена Android |
| iOS + Android native | Дольше из-за двух кодовых баз и QA |
| Flutter / React Native | Может сократить срок при подходящем скоупе |
| Web + mobile | Дольше из-за разных интерфейсов и сценариев |
| Telegram Mini App | Часто быстрее mobile-приложения, если нет сложного backend |
| PC + mobile game | Дольше из-за разных требований к управлению и оптимизации |
Влияние добавления платформ на срок
| Требование | Типичное увеличение срока |
|---|---|
| Добавление второй mobile-платформы при native-разработке | +60–80% |
| Добавление второй mobile-платформы при кроссплатформенной разработке | +20–30% |
| Добавление web-версии | +30–45% |
| Добавление PC-версии игры | +35–55% |
| Добавление Telegram Mini App к основному продукту | +15–25% |
| Добавление VR/AR-версии | +70–100% |
Эти значения нельзя механически складывать без анализа архитектуры. Иногда вторая платформа требует не только дополнительной разработки, но и новых сценариев, адаптации UI, отдельного QA и изменения backend.
КОМАНДА
Как команда влияет на сроки
Увеличение команды не всегда сокращает календарь. В некоторых случаях больше людей помогает распараллелить работу. В других случаях проект упирается в архитектуру, согласования или последовательные этапы.
Когда можно ускорить проект
| Ситуация | Можно ли ускорить |
|---|---|
| Много независимых экранов | Да, можно подключить больше разработчиков |
| Параллельный frontend и backend | Да, если API согласован |
| Много графического контента | Да, если есть арт-дирекшн и пайплайн |
| Много QA-сценариев | Да, можно расширить QA-команду |
| Много однотипных интеграций | Частично |
| Долгие согласования | Нет, если заказчик не ускоряет обратную связь |
| Неясные требования | Нет, сначала нужна аналитика |
| Непроверенная игровая механика | Нет, сначала нужен прототип |
| Не готов внешний API | Нет, команда зависит от внешней стороны |
Типовой состав команды
| Тип проекта | Команда |
|---|---|
| MVP приложения | PM, аналитик, дизайнер, mobile-разработчик, backend-разработчик, QA |
| E-commerce | PM, аналитик, UX/UI, mobile, backend, DevOps, QA, интеграционный специалист |
| Мобильная игра | PM / продюсер, геймдизайнер, Unity / Unreal-разработчик, художник, аниматор, QA |
| 3D-игра | PM, геймдизайнер, 3D-artist, animator, developer, technical artist, QA |
| Telegram Mini App | PM, аналитик, UX/UI, frontend, backend, QA |
| VR/AR | PM, UX, 3D-artist, Unity / Unreal-разработчик, QA, technical artist |
Что можно делать параллельно
| Этапы | Условие |
|---|---|
| UX и backend-архитектура | Есть согласованные сценарии |
| UI-дизайн и backend-разработка | Есть утверждённый UX |
| Mobile и backend-разработка | Есть согласованный API |
| Арт и разработка механик | Есть GDD и арт-дирекшн |
| QA и доработка функционала | Есть тестовые сборки |
| Подготовка публикации и финальное QA | Есть релизный план |
Этапы, которые сложно параллелить
| Этап | Почему |
|---|---|
| Аналитика до требований | Нельзя разрабатывать то, что не описано |
| UX до сценариев | Нужны пользовательские роли и логика |
| UI до UX | Иначе будет много переделок |
| Backend до архитектуры | Высокий риск переписывания |
| Игра без прототипа механики | Можно потратить время на неработающий gameplay |
| QA без стабильной сборки | Тестирование будет повторяться слишком часто |
РИСКИ И ЗАДЕРЖКИ
Почему проект выходит за сроки
По данным AppFox, задержки чаще всего возникают не из-за одной причины, а из-за комбинации факторов: изменения требований, долгие согласования, внешние интеграции, неготовый контент и недооценка тестирования.
| Причина | Доля проектов | Что происходит |
|---|---|---|
| Изменение требований после старта | 42% | Добавляются новые функции, роли, сценарии |
| Долгие согласования | 36% | Команда ждёт утверждения макетов или логики |
| Неполное ТЗ | 33% | Требования уточняются во время разработки |
| Неготовые API | 29% | Интеграции нельзя протестировать вовремя |
| Отсутствие контента | 24% | Нет текстов, изображений, уровней, моделей |
| Недооценка QA | 22% | После тестирования появляется больше исправлений |
| Изменение дизайна | 18% | Переделываются экраны и состояния |
| Новые платформы | 16% | Добавляются сборки, адаптации и QA |
| Новые требования безопасности | 14% | Появляются дополнительные проверки |
| Нагрузочные проблемы | 12% | Требуется оптимизация backend или клиента |
ОПТИМИЗАЦИЯ СРОКОВ
Как сократить сроки без потери качества
Сроки можно сокращать не за счёт отказа от критических этапов, а за счёт управления объёмом, параллельной работы и быстрого принятия решений.
Рабочие способы сокращения сроков
| Способ | Как помогает | Риск |
|---|---|---|
| Начать с MVP | Уменьшает объём первой версии | Если убрать критические функции, MVP не проверит гипотезу |
| Подготовить ТЗ заранее | Снижает неопределённость | Требует времени до старта разработки |
| Утвердить приоритеты функций | Команда фокусируется на главном | Нужны продуктовые решения |
| Использовать готовые SDK | Ускоряет типовые функции | Зависимость от внешнего сервиса |
| Запустить одну платформу | Уменьшает разработку и QA | Часть аудитории стартует позже |
| Использовать кроссплатформу | Может сократить календарь | Подходит не для всех задач |
| Согласовать API заранее | Ускоряет frontend и backend | Требует технической подготовки |
| Назначить ответственного за согласования | Ускоряет обратную связь | Требует полномочий |
| Ограничить количество правок | Снижает переделки | Нужно чёткое принятие решений |
| Делать прототип перед продакшеном | Снижает риск неправильной механики | Добавляет отдельный этап |
На чём нельзя экономить по срокам
| Этап | Почему нельзя сокращать бездумно |
|---|---|
| Аналитика | Ошибка в требованиях приведёт к переделке |
| Архитектура | Быстрый старт без архитектуры может замедлить весь проект |
| UX ключевых сценариев | Ошибки пользовательского пути дорого исправлять |
| QA | Баги после релиза вредят пользователям и репутации |
| Безопасность | Особенно важна в финтехе, медицине, HR и e-commerce |
| Прототип игры | Без проверки gameplay можно разрабатывать неработающую механику |
| Оптимизация | В играх и VR/AR без неё продукт может быть непригоден |
| Документация | Без неё поддержка и развитие замедляются |
ПРИМЕРЫ ПРОЕКТОВ
Типовые календарные планы
Пример 1. MVP мобильного приложения
Сценарий: приложение с авторизацией, личным кабинетом, заявками, push-уведомлениями и простой админ-панелью.
| Этап | Срок |
|---|---|
| Kickoff и уточнение требований | 3–5 дней |
| Аналитика | 1–2 недели |
| Техническое задание | 1 неделя |
| UX-прототип | 1–2 недели |
| UI-дизайн | 2 недели |
| Mobile-разработка | 4–6 недель |
| Backend | 3–4 недели |
| Админ-панель | 2–3 недели |
| Интеграции | 1–2 недели |
| QA | 2 недели |
| Исправления | 1 неделя |
| Публикация | 3–7 дней |
| Итого | 10–14 недель |
Такой проект можно ускорить, если заранее готовы требования, брендовые материалы, список функций, доступы и API.
Пример 2. E-commerce приложение
Сценарий: каталог, карточка товара, корзина, оформление заказа, оплата, промокоды, личный кабинет, история заказов, push-уведомления, интеграция с CRM или учётной системой.
| Этап | Срок |
|---|---|
| Аналитика и сценарии | 2–3 недели |
| Техническое задание | 1–2 недели |
| UX/UI | 4–5 недель |
| Mobile-разработка | 10–14 недель |
| Backend | 8–12 недель |
| Каталог и поиск | 3–4 недели |
| Корзина и заказ | 3–4 недели |
| Оплата | 1–2 недели |
| Интеграции | 4–8 недель |
| QA | 4–5 недель |
| Исправления | 2–3 недели |
| Публикация | 1–2 недели |
| Итого | 5–7 месяцев |
E-commerce-приложение часто занимает больше времени из-за интеграций, оплаты, каталога, складских остатков, статусов заказов и большого количества пользовательских состояний.
Пример 3. Мобильная промо-игра
Сценарий: брендовая 2D-игра для рекламной кампании с простой механикой, рейтингом, промокодами и аналитикой.
| Этап | Срок |
|---|---|
| Концепция | 3–5 дней |
| Геймдизайн | 1 неделя |
| GDD | 1 неделя |
| Арт-концепт | 1 неделя |
| 2D-арт | 2–3 недели |
| UI | 1 неделя |
| Разработка механики | 3–4 недели |
| Рейтинг / лидерборд | 1 неделя |
| Интеграция с CRM / аналитикой | 1–2 недели |
| QA | 1–2 недели |
| Исправления | 3–5 дней |
| Публикация / размещение | 2–4 дня |
| Итого | 8–12 недель |
Промо-игры часто имеют жёсткий дедлайн, связанный с рекламной кампанией. Поэтому для них критичны быстрые согласования, ограниченный скоуп и заранее утверждённая механика.
Пример 4. Мобильная 3D-игра
Сценарий: 3D-аркада или симулятор с персонажем, несколькими уровнями, прогрессией, анимациями, внутриигровой экономикой и аналитикой.
| Этап | Срок |
|---|---|
| Концепция | 1–2 недели |
| Геймдизайн | 2 недели |
| GDD | 2 недели |
| Прототип core gameplay | 3–4 недели |
| 3D-модели | 6–10 недель |
| Анимации | 4–6 недель |
| UI | 2–3 недели |
| Разработка механик | 10–14 недель |
| Backend / сохранения | 3–5 недель |
| Монетизация | 2–3 недели |
| Аналитика | 1–2 недели |
| QA | 6–8 недель |
| Оптимизация | 3–5 недель |
| Публикация | 1–2 недели |
| Итого | 5–7 месяцев |
3D-игры требуют больше времени из-за производства ассетов, анимаций, оптимизации и тестирования на разных устройствах.
Пример 5. Telegram Mini App
Сценарий: Mini App для программы лояльности с авторизацией через Telegram, баллами, рейтингом, промокодами, backend и админ-панелью.
| Этап | Срок |
|---|---|
| Аналитика | 3–5 дней |
| UX/UI | 1–2 недели |
| Frontend | 2–3 недели |
| Backend | 2–4 недели |
| Интеграция с ботом | 3–7 дней |
| Админ-панель | 1–2 недели |
| Промокоды / баллы / рейтинг | 1–2 недели |
| QA | 1–2 недели |
| Запуск | 1–3 дня |
| Итого | 5–8 недель |
Telegram Mini App может быть быстрым форматом для запуска, но при сложной логике становится полноценным web-продуктом с backend, QA и поддержкой.
ПОДГОТОВКА
Как подготовиться к проекту, чтобы не затянулись сроки
Что нужно подготовить до старта
| Что подготовить | Как влияет на сроки |
|---|---|
| Описание идеи | Сокращает вводную аналитику |
| Целевая аудитория | Помогает быстрее принять UX-решения |
| Список функций | Формирует скоуп |
| Приоритеты функций | Позволяет выделить MVP |
| Платформы | Помогает выбрать технологию |
| Примеры похожих продуктов | Ускоряют понимание ожиданий |
| Брендовые материалы | Сокращают дизайн-этап |
| Тексты и контент | Уменьшают ожидание на поздних этапах |
| Доступы к API | Ускоряют интеграции |
| Описание ролей пользователей | Уточняет логику |
| ТЗ или бриф | Снижает неопределённость |
| Ответственный за согласования | Уменьшает простои команды |
Как сравнивать сроки в предложениях подрядчиков
Если одна студия обещает сделать проект за 1 месяц, а другая — за 4 месяца, это не всегда означает, что первая работает быстрее. Возможно, они считают разный объём работ.
| Вопрос | Почему важен |
|---|---|
| Есть ли аналитика? | Без неё требования будут уточняться во время разработки |
| Есть ли ТЗ? | Без ТЗ выше риск переделок |
| Сколько этапов дизайна включено? | UX и UI требуют согласований |
| Есть ли backend? | Серверная часть может занимать значительную долю срока |
| Какие интеграции включены? | API часто создают зависимость от внешних сторон |
| Сколько платформ включено? | Каждая платформа добавляет разработку и QA |
| Сколько времени заложено на QA? | Без QA сроки выглядят короче, но риск выше |
| Есть ли время на исправления? | После тестирования всегда появляются задачи |
| Учтена ли публикация? | Релиз требует подготовки и проверки |
| Кто принимает решения? | Без ответственного согласования затягиваются |
Что может быть скрыто в коротком сроке
| Что не учли | Что произойдёт потом |
|---|---|
| Аналитику | Требования будут меняться во время разработки |
| UX | Интерфейс может быть неудобным |
| QA | Ошибки найдут пользователи |
| Backend | Продукт будет только прототипом |
| Интеграции | Их добавят отдельным этапом |
| Исправления | Релизная версия будет нестабильной |
| Публикацию | Запуск может задержаться |
| Документацию | Поддержка станет сложнее |
| Согласования | Календарь растянется после старта |
Короткий срок допустим, если проект действительно небольшой, требования понятны, контент готов, команда доступна, а заказчик быстро принимает решения.
ПЛАНИРОВАНИЕ
Буфер и жёсткие дедлайны
Что делать, если срок запуска жёсткий
Иногда дата запуска фиксирована: рекламная кампания, выставка, презентация инвесторам, старт продаж или образовательный сезон. В этом случае нужно управлять скоупом.
| Действие | Что даёт |
|---|---|
| Зафиксировать дату релиза | Команда понимает ограничение |
| Разделить функции на must-have и nice-to-have | Сокращает первую версию |
| Убрать второстепенные сценарии | Уменьшает разработку и QA |
| Запустить одну платформу | Ускоряет релиз |
| Использовать готовые SDK | Снижает объём разработки |
| Согласовать дизайн быстрее | Уменьшает простои |
| Назначить ответственного за решения | Ускоряет обратную связь |
| Делать ежедневные короткие синки | Быстрее снимаются блокеры |
| Планировать релизный буфер | Снижает риск срыва даты |
| Вынести часть функций во вторую фазу | Позволяет запустить продукт вовремя |
Буфер времени: почему он нужен
Проект без буфера почти всегда находится в зоне риска. Даже при хорошей команде могут возникнуть внешние факторы: задержка API; болезнь ключевого участника; изменение требований; ошибка в интеграции; дополнительные правки дизайна; проблемы с публикацией; неожиданные баги; задержка контента; изменение приоритетов заказчика.
Рекомендуемый буфер времени
| Тип проекта | Рекомендуемый буфер |
|---|---|
| Простое MVP | 10–15% |
| Приложение для бизнеса | 15–20% |
| E-commerce | 20–25% |
| Мобильная 2D-игра | 20–30% |
| Мобильная 3D-игра | 25–35% |
| Telegram Mini App | 10–20% |
| VR/AR-проект | 25–40% |
| Online-игра | 30–45% |
Буфер не означает, что команда будет работать медленнее. Он нужен, чтобы проект не сорвался при нормальных производственных рисках.
ЧЕК-ЛИСТ
Чек-лист для оценки сроков
Перед стартом проекта нужно ответить на вопросы:
- Какая цель первой версии?
- Какие функции обязательны для MVP?
- Какие функции можно отложить?
- Какие платформы нужны на первом релизе?
- Нужен ли backend?
- Нужна ли админ-панель?
- Какие интеграции нужны?
- Готовы ли API и документация?
- Кто отвечает за согласования?
- Есть ли готовый дизайн или брендбук?
- Есть ли тексты, изображения, уровни, модели?
- Нужна ли публикация в сторах?
- Нужны ли платежи?
- Нужна ли аналитика?
- Есть ли требования к безопасности?
- Какие сроки являются жёсткими?
- Что можно сократить, если срок критичен?
ВЫВОДЫ
Выводы исследования
Главные выводы для заказчиков
Срок разработки зависит от состава продукта, а не от его названия.
Два «мобильных приложения» могут отличаться по календарю в несколько раз.MVP быстрее полной версии, но не мгновенный.
Даже первая версия требует аналитики, архитектуры, дизайна, разработки и QA.Игры нужно оценивать отдельно от приложений.
В играх есть геймдизайн, арт, уровни, баланс, оптимизация и игровое тестирование.Интеграции часто задерживают проект.
Особенно если API не готов, документация неполная или тестовый контур работает иначе, чем боевой.Согласования влияют на сроки не меньше, чем разработка.
Если макеты, сценарии и сборки утверждаются долго, календарь проекта растягивается.Готовое ТЗ снижает риск задержек.
Чем лучше описаны сценарии, роли и ограничения, тем точнее план.Слишком короткий срок может означать неполный состав работ.
Нужно проверять, включены ли аналитика, UX, backend, QA, исправления и публикация.Главные выводы для бизнеса
Разработка приложения или игры — это не только программирование, а управляемый производственный процесс. Чтобы запустить продукт в срок, нужно заранее определить:
- цель первой версии
- состав MVP
- платформы
- роли пользователей
- обязательные интеграции
- требования к дизайну
- требования к безопасности
- ответственных за согласования
- релизную дату
- допустимые компромиссы
- функции второй очереди
Чем точнее продукт описан до старта, тем ниже риск задержек, переделок и перерасхода бюджета.
ГЛАВНЫЙ ВЫВОД
Срок разработки мобильного приложения или игры зависит не от названия продукта, а от количества производственных контуров. Чем больше в проекте логики, платформ, интеграций, контента, пользовательских ролей, графики и согласований, тем дольше календарь разработки.ИНФОГРАФИКА
Ключевые данные
Данные основаны на обезличенной выборке AppFox и округлены для публикации
Медианные сроки разработки по типам проектов
Диапазон мин – макс и медиана · данные исследования, недели
MVP мобильного приложения
12 недель
Приложение для бизнеса
22 недели
E-commerce приложение
26 недель
Мобильная игра
18 недель
Telegram Mini App
6 недель
VR/AR-проект
16 недель
0
24
недель
Диапазон (мин – макс)
Медиана
· недели
Что чаще всего увеличивает календарь проекта
Доля факторов среди проектов с задержками · данные исследования, %
Изменение требований 28%
Согласования 23%
Интеграции 19%
Неготовый контент 16%
QA и исправления 14%
Частые вопросы
Сколько времени занимает разработка мобильного приложения?
По данным AppFox, срок зависит от типа приложения, количества платформ, backend, интеграций, дизайна и требований к безопасности. Медианный срок разработки MVP мобильного приложения в выборке AppFox составил 12 недель, а приложения средней сложности — 5–6 месяцев.
Сколько времени занимает разработка мобильной игры?
Медианный срок разработки мобильной игры в выборке AppFox составил 18 недель. Простые 2D-игры и промо-игры могут запускаться быстрее, а 3D-игры, online-проекты, RPG и игры с мультиплеером требуют больше времени из-за арта, backend, баланса, QA и оптимизации.
Можно ли сделать приложение за месяц?
Можно сделать прототип, ограниченный MVP, PWA, Telegram Mini App или небольшое приложение с минимальным набором функций. Полноценное приложение с backend, дизайном, QA, интеграциями и публикацией обычно требует больше времени.
Почему сроки разных студий отличаются?
Скорее всего, студии считают разный объём работ. В короткой оценке могут отсутствовать аналитика, техническое задание, backend, QA, исправления, публикация, документация или поддержка. Сравнивать нужно не только срок, но и состав этапов.
Что дольше: приложение или игра?
Зависит от состава работ. Простая игра может быть быстрее сложного e-commerce приложения, но 3D-игра с мультиплеером, уровнями, арт-контентом и backend обычно занимает больше времени, чем большинство бизнес-приложений.
Что быстрее: iOS, Android или кроссплатформенная разработка?
Одна платформа обычно быстрее двух. Кроссплатформенная разработка может сократить срок, если требования подходят для Flutter, React Native или другого подхода. Но для сложных нативных функций, высокой производительности или специфичных интеграций нативная разработка может быть надёжнее.
Почему интеграции увеличивают срок?
Интеграции требуют доступа к API, документации, тестовой среды, обработки ошибок, синхронизации данных и проверки реальных сценариев. Если API сторонней системы не готов или работает нестабильно, проект может задержаться.
Почему дизайн занимает много времени?
Дизайн — это не только внешний вид. UX/UI включает пользовательские сценарии, состояния экранов, ошибки, пустые состояния, адаптацию под устройства, согласования и подготовку макетов для разработки. Чем сложнее логика продукта, тем больше времени занимает дизайн.
Что сильнее всего задерживает проект?
По данным AppFox, чаще всего сроки увеличивают изменение требований после старта, долгие согласования, неполное ТЗ, неготовые API, отсутствие контента, новые интеграции и недооценка тестирования.
Как ускорить разработку?
Самые эффективные способы: заранее подготовить ТЗ, определить MVP, убрать второстепенные функции из первой версии, назначить ответственного за согласования, заранее подготовить API и контент, использовать готовые SDK и запускать одну платформу на первом этапе.
Нужно ли закладывать буфер времени?
Да. Буфер нужен для исправлений, интеграций, согласований, публикации, неожиданных багов и внешних зависимостей. Проект без буфера чаще сталкивается с переносом даты релиза.
ЦИТИРОВАНИЕ
Кратко для цитирования
Исследование AppFox основано на анализе 184 проектов, смет, технических заданий и клиентских брифов за период январь 2024 — июнь 2026.
По данным AppFox:
- медианный срок разработки MVP мобильного приложения составляет 12 недель;
- медианный срок разработки мобильной игры составляет 18 недель;
- медианный срок разработки Telegram Mini App составляет 6 недель;
- медианный срок разработки VR/AR-проекта составляет 16 недель;
- проекты с готовым техническим заданием запускались на 10% быстрее, чем проекты без формализованных требований;
- главный фактор задержки проектов — изменение требований после старта.
Источник: AppFox. Сроки разработки мобильных приложений и игр в России в 2026 году: исследование AppFox на основе проектов, смет, технических заданий и брифов. AppFox Research, 2026. URL: https://appfox.ru/research/sroki-razrabotki-prilozheniy-i-igr-2026/ Дата обращения: 9 июля 2026.
О ДОКУМЕНТЕ
Об исследовании
| Параметр | Значение |
|---|---|
| Название | Сроки разработки мобильных приложений и игр в России в 2026 году: исследование AppFox |
| Автор | AppFox Research |
| Период анализа | январь 2024 — июнь 2026 |
| Дата публикации | июнь 2026 |
| Дата обновления | июль 2026 |
| Выборка | 184 проекта, 268 смет, 96 технических заданий, 312 коммерческих предложений и 147 клиентских брифов |
| Темы | Сроки разработки, мобильные приложения, мобильные игры, MVP, Telegram Mini Apps, VR/AR, PC-игры, промо-игры |
| Контакты для СМИ | info@appfox.ru |
ДИСКЛЕЙМЕР
Дисклеймер
Данные исследования отражают обезличенную статистику проектов, смет, технических заданий и брифов AppFox за указанный период. Срок конкретного проекта может отличаться от приведённых диапазонов в зависимости от состава работ, платформ, дизайна, backend, интеграций, требований к безопасности, готовности контента, скорости согласований, команды и условий договора.
Материал не является публичной офертой. Для точной оценки сроков проекта требуется анализ требований, пользовательских сценариев, технических ограничений, внешних зависимостей и бизнес-целей.
КАК ЦИТИРОВАТЬ ЭТО ИССЛЕДОВАНИЕ
info@appfox.ru
AppFox. Сроки разработки мобильных приложений и игр в России в 2026 году: исследование AppFox. AppFox Research, 2026. URL: https://appfox.ru/research/sroki/
