Сколько времени занимает разработка мобильного приложения

Реальные сроки для проектов разного размера

Это ориентиры для планирования, а не обещание точной даты. Они предполагают, что над продуктом работает небольшая опытная команда, заказчик отвечает без многонедельных пауз, а критические юридические и технические вопросы не оставлены на конец.

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

Как лоукод и AI меняют срок разработки

Две недели — реалистичный ориентир для интерактивного AI-прототипа или очень узкого пилота, но не для любого рабочего продукта. Современные инструменты быстро создают начальную версию: FlutterFlow Designer собирает редактируемый набор экранов по текстовому описанию, а в руководстве Replit Agent первая рабочая заготовка генерируется за несколько минут. Оставшееся время нужно на исправление результата, подключение ограниченного набора настоящих данных, проверку главного сценария и подготовку демонстрации.

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

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

Поэтому разумный план может выглядеть так: около двух недель на AI-прототип, один-два месяца на лоукод-пилот и отдельный этап заказной разработки только после подтверждения спроса. Если пилот становится важной частью работы компании, заранее спланируйте его усиление или перенос по чек-листу перехода с no-code MVP, пока данные и процессы еще легко перенести.

Из каких этапов складывается календарь

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

По данным Apple, в среднем 90% отправленных приложений рассматриваются менее чем за 24 часа. Google советует учитывать от нескольких часов до семи дней, а в исключительных случаях — больше. Это время проверки, а не гарантия публикации. Если не работает тестовый аккаунт или неверно заполнен раздел о данных, потребуется исправление и повторная отправка.

Пример: приложение для записи за 16 недель

Представим сервис, в котором клиент регистрируется, выбирает услугу и свободное время, вносит предоплату и получает напоминание. Сотрудники управляют расписанием через небольшую панель администратора.

Такой план работает, если правила решены заранее. Если на десятой неделе еще обсуждаются штраф за отмену, рабочее время специалистов и возврат предоплаты, придется менять интерфейс, серверную логику, тесты и уведомления.

Разработка и ожидание — не одно и то же

Подключение платежей может занять у программиста один день, а открытие и проверка расчетного кабинета — две недели. Дизайнер может быстро исправить экран, но ждать решения пяти руководителей до следующего совещания.

В хорошем плане отдельно видны:

• работа команды;
• решения, тексты и материалы заказчика;
• сроки открытия аккаунтов и ответа сторонних сервисов;
• время на проверку каждого промежуточного результата;
• запас на рискованные интеграции и замечания магазинов.

У каждой зависимости должны быть ответственный и дата. Фраза «заказчик предоставит доступ» ничего не гарантирует. Формулировка «руководитель проекта передает тестовый доступ до 12 августа, иначе подключение оплаты переносится на следующий этап» позволяет заранее понять последствия.

Какие работы можно вести одновременно

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

Но некоторые решения нельзя безболезненно отложить: роли пользователей, главный источник данных, модель оплаты, владелец аккаунтов и основная навигация влияют почти на весь продукт. Если начать все направления без этих ответов, занятость будет высокой, а настоящий прогресс — случайным.

Официальное руководство Scrum определяет короткие рабочие циклы продолжительностью не более месяца. За каждый цикл команда создает и проверяет полезную часть продукта. Это не означает, что большое приложение непременно готово через два или три таких цикла.

Что сильнее всего меняет срок

Каждая роль добавляет права, состояния и отдельные сценарии. В маркетплейсе различаются покупатель, продавец и администратор. Для доставки может потребоваться второе приложение курьера и рабочее место диспетчера.

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

Перенос данных тоже требует подготовки: очистки, сопоставления полей, поиска повторов, пробного запуска и способа отката. Наличие списка клиентов в таблице еще не означает, что данные готовы к загрузке.

На срок влияет и требуемый уровень качества. Доступность для людей с ограничениями, планшеты, несколько языков, работа без сети, старые устройства Android и медицинские данные увеличивают количество решений и проверок.

Что заказчик может сделать заранее

Назначьте человека, который вправе принимать продуктовые решения и собирать замечания остальных участников. Согласуйте срок ответа. Иначе каждая демонстрация будет останавливаться на неделю из-за противоречивых комментариев.

Подготовьте то, что команда не должна придумывать за бизнес: правила, цены, настоящие тексты, корпоративные аккаунты, доступ к поставщикам и ответственных за безопасность или персональные данные. Отделите обязательное для запуска от улучшений на будущее.

Документ с требованиями к продукту помогает сохранить общую цель и приоритеты, пока календарь становится подробнее.

Как ускорить проект без потери качества

Самый надежный способ сократить срок — уменьшить первую версию. Оставьте один основной сценарий, ограничьте роли, а часть редких операций на пилоте выполняйте вручную. Отказ от восстановления доступа, тестов и сбора ошибок лишь переносит затраты на период после запуска.

Общая технология для iOS и Android может сократить повторяющуюся работу, когда приложения ведут себя одинаково. Она не отменяет серверную часть, проектирование, интеграции, проверку на устройствах и подготовку магазинов.

Еще один вариант — ограниченный выпуск через TestFlight и каналы тестирования Google Play. Реальные пользователи помогут найти непонятные места до массового запуска, если команда видит аналитику, отвечает на обращения и умеет остановить неудачное обновление.

Как проверить срок в коммерческом предложении

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

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

Как мы планируем запуск в Appfyl

В Appfyl первоначальный диапазон срока связан с конкретными предположениями: ролями, главным сценарием, возможностями панели администратора, интеграциями, готовностью дизайна и рынками запуска. Затем мы превращаем его в этапы с проверяемым результатом.

Мы предпочитаем показывать работающие цепочки. Запись, которая проходит от выбора времени до подтверждения сотрудником, говорит о состоянии проекта больше, чем фраза «разработка готова на 70%». Открытые решения и сторонние зависимости остаются видимыми рядом с техническими задачами.

Интерактивный бриф Appfyl помогает упорядочить функции до обсуждения срока. Последние недели удобно планировать по списку проверок перед запуском и плану публикации приложения.

Посмотрите, как Appfyl превращает объем работ в запущенные продукты. Смотреть кейсы Appfyl.

Частые вопросы