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

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

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

За что платит заказчик при разработке

Приложение на телефоне

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

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

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

Сервер и инструменты для сотрудников

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

Готовый сайт или CRM иногда позволяют использовать существующие данные и часть бизнес-логики. Но сначала разработчикам нужно проверить, можно ли получить нужную информацию и выполнять необходимые действия. Наличие интернет-магазина ещё не означает, что все его функции доступны для мобильного приложения.

В проекте Apeti из портфолио Sibcode приложение доставки использует действующий интернет-магазин как базу данных. В описании проекта также указаны подключение SMS для авторизации и поиск Elasticsearch. Этот пример показывает, почему при оценке приложения нужно учитывать существующую инфраструктуру и отдельные подключения.

Что меняет объём работ

Платформы и возможности устройства

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

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

Вопросы выбора формата подробнее рассмотрены в обзоре мобильной разработки в блоге Sibcode. Для сметы важно определить подходящий вариант под нужные действия пользователя, а затем оценить полный состав работ.

Обмен данными и нестандартные сценарии

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

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

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

Что должно входить в оценку первого релиза

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

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

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

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

Расходы после публикации

Инфраструктура и внешние сервисы

Приложение может продолжать использовать платные ресурсы после завершения разработки. В зависимости от проекта это:

• Серверы, базы данных и хранение файлов.
• SMS, карты и другие внешние сервисы.
• Мониторинг, сбор ошибок и резервное копирование.
• Аккаунты разработчика и платные инструменты, если они нужны для выбранного способа распространения.

Для каждой позиции полезно знать, как начисляется плата и при каких условиях она вырастет. Количество пользователей не всегда прямо определяет расходы. Значение могут иметь частота запросов, объём изображений, число отправленных сообщений и сроки хранения данных.

Поддержка и совместимость

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

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

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

Новые функции

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

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

Подготовка к публикации тоже требует работы

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

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

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

Как рассчитать бюджет своего приложения

Начните с действия, ради которого пользователи будут возвращаться в приложение. В условном сервисе записи это выбор услуги и времени, подтверждение записи и возможность её изменить. Дополнительные функции можно оценить отдельно, сохранив полноценность основного сценария.

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

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

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