Сроки разработки мобильного приложения: как проверить оценку подрядчика до договора

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

Реальные сроки разработки мобильного приложения — от 3 до 9 месяцев для среднего проекта, и это если команда опытная, а требования зафиксированы. Но «средний проект» — понятие растяжимое, как резиновые штаны после новогоднего стола. Один и тот же функционал может стоить 800 часов у ответственной студии и 2000 часов у аутсорса, который гонит метры кода вместо решения задачи. Поэтому прежде чем подписывать договор, нужно провести самостоятельную экспертизу сметы. Не «посмотреть и кивнуть», а именно провести — с калькулятором, здравым смыслом и пониманием, откуда берутся цифры в тех строках Excel-файла, который вам прислали на согласование.

Математика сметы: как перевести часы в календарные дни

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

Типичная выработка одного разработчика — 120–140 часов в месяц. Это не «сидение в офисе», а реальные часы продуктивной работы, после вычета совещаний, код-ревью, перекуров и борьбы с инфраструктурой. Значит, 900 часов — это не два месяца, а 6,5–7,5 месяцев работы одного специалиста. Или 3,5 месяца, если в команде два разработчика. Но параллельная работа не линейна: два программиста не делают за месяц вдвое больше, потому что появляются точки синхронизации, мерж-конфликты и необходимость архитектурных договорённостей.

Формула простая. Берёте заложенные в смете часы по каждой роли, делите на 130 (усреднённая месячная выработка) и получаете количество человеко-месяцев. Потом смотрите, сколько специалистов подрядчик планирует привлечь параллельно, и делите. Результат — реальная календарная длительность.

Вот как это выглядит на практике:

Теперь вы видите реальную картину. Если подрядчик при этих цифрах обещает запуск за три месяца — он либо планирует армию из восьми разработчиков (и вам придётся за это заплатить), либо не понимает собственной сметы. Или — что тоже бывает — надеется, что «мы как-нибудь уложимся», а потом начнутся переносы.

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

Факторы замедления: почему Android и интеграции требуют больше времени

Разделите смету на две категории: «базовый функционал» и «всё остальное». Базовый — это экраны, навигация, логин, простые формы. Всё остальное — это интеграции, и именно они убивают сроки.

Вот реальные цифры по отдельным функциям, которые часто недооценивают:

• Базовый чат — около 2 недель. Кажется просто? Это без учёта push-уведомлений, хранения истории, отправки файлов и модерации.
• Видеочат — до 6 недель. WebRTC-интеграция, обработка плохого соединения, запись, шифрование — каждый слой добавляет дни.
• Интеграция с картами — 1–2 недели для базового сценария, но если нужны геозоны, маршрутизация и кастомные маркеры — умножайте на два.
• Интеграция с внешними API — 1–2 недели на каждую систему, и это если документация API хорошая и контрагент отвечает на вопросы в течение дня. Если нет — добавляйте буфер на «ожидание ответа от третьей стороны».
• Интеграция с 1С — до 1 месяца. Отдельный круг ада, потому что API 1С — это не REST, а специфический мир со своими правилами, и разработчик, который с ним не работал, потратит первую неделю на чтение документации и маты.

Android-разработка исторически требует на 20–30% больше времени, чем iOS, не потому что Android-разработчики медленнее, а потому что фрагментация. Более 12 000 видов Android-устройств, десятки разрешений экрана, разные версии операционной системы — QA тестирует на десятках конфигураций вместо пяти-шести iPhone.

Выбор стека как инструмент ускорения: Flutter против натива

В 2026 году выбор между нативной и кроссплатформенной разработкой — не вопрос «веры», а вопрос арифметики. Flutter позволяет ускорить запуск приложения в 1,3–1,5 раза по сравнению с созданием двух отдельных нативных продуктов. Это значит, что если нативный цикл занимает 9 месяцев, Flutter может уложить в 6–7.

Но не всё так радужно, как рисуют маркетологи Google.

Когда Flutter реально экономит время:

• Типовое приложение с типовым UI (каталог, карточки, формы, чаты)
• Ограниченный бюджет, но нужен запуск на обеих платформах
• Нет требований к глубокой интеграции с платформенными API (камера, Bluetooth, AR)

Когда Flutter добавляет головной боли:

• Сложные нативные интеграции (платёжные SDK, банковские модули, IoT-протоколы) — обёртки на Dart не всегда стабильны, и время «допиливания» может съесть экономию
• Высокие требования к производительности — анимации и тяжёлые списки в Flutter работают хорошо, но не идеально, и «последняя миля» оптимизации требует усилий
• Команда, которая не знает Flutter — кривая обучения добавит 4–8 недель к первому проекту

Flutter — это не магическая кнопка «сделать быстрее». Это инструмент, который экономит время на типовых сценариях, но заставляет платить за нетиповые. Перед выбором стека посчитайте: сколько ваших экранов — типовые, а сколько требуют нативных решений.

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

Анализ рыночных ставок и продуктивности команды в 2026 году

Когда вы видите итоговую сумму в смете, полезно разложить её обратно на ставки и проверить: а не завышает ли подрядчик стоимость часа? Или — что хуже — не занижает ли, чтобы получить контракт, а потом «доить» на допработах?

Рыночные ставки сильных студий мобильной разработки в 2026 году:

Возьмём пример. Смета подрядчика: 1730 часов, итого 6,8 млн рублей. Средняя ставка — 3 930 руб./час. Смотрим на таблицу: это укладывается в диапазон для команды уровня Middle–Senior, что адекватно. Если бы средняя ставка была 1 500 руб./час — это сигнал: или команда джуниоры (и сроки нужно умножать на 1,5–2), или это «входная» цена с последующими доплатами.

Арифметика продуктивности помогает и в другом направлении. Если подрядчик говорит «4 разработчика на 3 месяца», это 4 × 130 × 3 = 1 560 часов. А в смете — 1 730. Значит, либо они не уложатся в три месяца, либо часть часов ляжет на параллельные роли (дизайнер, QA), что нормально. Но расхождение видно, и его можно обсудить до подписания, а не после первого срыва.

Стратегия безопасности: как закладывать буфер на непредвиденные правки

Вот факт, который подрядчики редко озвучивают сами: ни один проект мобильной разработки не прошёл без правок после старта. Требования меняются. Заказчик видит первую версию и понимает, что «это не то, что я имел в виду». Внешний API оказывается документирован криво. Дизайнер передумал. Бэкенд-разработчик ушёл в отпуск.

Профессиональные студии закладывают в план 2–4 недели буфера на непредвиденные факторы. Это не «запас на лень», а инженерная норма — как коэффициент запаса прочности в строительстве. Если подрядчик показывает вам план без буфера — спросите, почему. Возможно, он просто не показал, а заложил внутрь этапов. А возможно — не заложил, и тогда первый же сбой в цепочке развалит весь календарь.

Частичное совмещение этапов — ещё один рычаг экономии времени. Когда разработчики начинают писать код, пока дизайнер дорабатывает последние экраны, можно сэкономить 2–3 недели. Но это работает только при условии, что UX/UI на 80% согласован: если дизайн «плавает», совмещение превращается в костыли, которые потом переписываются.

Что заложить в договор для защиты сроков:

1. Фиксацию промежуточных этапов с конкретными датами и критериями приёмки — не «дизайн», а «12 экранов в Figma, согласованных заказчиком»

2. Буфер в 2–4 недели поверх оценки подрядчика — как в вашем внутреннем плане, так и в ожиданиях стейкхолдеров

3. Процедуру обработки изменений: если вы добавляете функцию после старта, это не «мелкая доработка», а пересчёт часов и сроков

4. Еженедельные демо — не отчёты в мессенджере, а работающий продукт на экране. Если на третьей неделе нет видимого прогресса — это тревожный сигнал

Хорошая смета — это не гарантия сроков. Это инструмент, с которым вы можете задать правильные вопросы до того, как подрядчик начнёт списывать просрочку на «объективные сложности».

Вердикт: считайте сами, даже если доверяете подрядчику

Проверка оценки подрядчика — не про недоверие. Это про ответственность за свой бюджет и свои сроки. Подрядчик заинтересован в контракте и будет оптимистичен в прогнозах — это нормально, это бизнес. Но ваша задача — посмотреть на те же цифры сквозь призму реальности: 130 часов в месяц на разработчика, 20–30% накрутки на Android, недели на интеграции, буфер на непредвиденное.

Реальные сроки разработки мобильного приложения — от 2–3 месяцев для простого MVP до года и более для сложных систем с интеграциями. Если оценка подрядчика укладывается в эти рамки после перевода часов в календарь и проверки ставок — проект стартует с прочного фундамента. Если не укладывается — вы узнаете об этом до подписания договора, а не после третьего переноса дедлайна.