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

Бюджет шире, чем цена разработки

Цена разработки отвечает на узкий вопрос: какую работу выполнит команда и что передаст заказчику? Бюджет отвечает на более практичный вопрос: за что ещё придётся заплатить и какие решения нужно принять, чтобы выпустить полезный продукт и поддерживать его работу?

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

Четыре части реалистичного бюджета

Эта схема помогает разложить будущие расходы по местам ещё до того, как команда превратит описание проекта в подробную смету.

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

Сначала определите результат, а потом перечисляйте функции

Первый вопрос звучит не так: «Сколько экранов нам нужно?». Гораздо полезнее спросить: «Что должен суметь сделать пользователь и какое бизнес-решение мы примем после первого запуска?»

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

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

Превратите список функций в понятные сценарии

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

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

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

Платформы, пользователи и технические ограничения

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

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

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

Учтите публикацию и первый год работы

Публикация не сводится к одной кнопке. Для App Store нужен аккаунт разработчика, а Google Play также требует регистрацию и подтверждение аккаунта. Перед утверждением бюджета проверьте актуальные условия в Apple Developer Program и документации Google Play Console.

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

Ориентиры Appfyl для готового продукта

В Appfyl мы используем три диапазона, чтобы начать разговор о проекте. Это ориентиры для планирования, а не окончательная смета.

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

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

Четыре примера разного объёма

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

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

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

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

Сравнивайте предложения по допущениям

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

Если одно предложение заметно дешевле, ищите разницу в допущениях. Не включены исследование продукта, UX, серверная часть, перенос данных, QA, работа с магазинами или поддержка? Цена рассчитана только на одну платформу? Серверы и API оплачиваются отдельно? Явный список работ полезнее, чем мнимая точность одной цифры.

Разделите бюджет на последовательные решения

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

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

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