#Price#Mobile#Guide

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

АвторArt.Vision Team

«Сколько стоит приложение?» — вопрос без ответа, пока неизвестно, что оно должно делать. Но вилку назвать можно, и разброс в ней объясняется вполне конкретными вещами. Ниже — из чего реально складывается смета.

Четыре фактора, которые двигают цену

  • Количество экранов. Не сам список, а число состояний: загрузка, пустой список, ошибка сети, нет доступа. Один экран каталога — это в среднем четыре состояния, каждое надо нарисовать и запрограммировать.
  • Платформы. Две нативные команды стоят примерно вдвое дороже одной кроссплатформенной. Об этом отдельно ниже.
  • Серверная часть. Если данные берутся из вашей учётной системы, приложение — это половина работы. Вторая половина — API, авторизация, синхронизация.
  • Интеграции. Оплата, доставка, телефония, 1С. Каждая — отдельный срок и отдельная строка бюджета.

Три сценария и их вилки

MVP — от 250 000 ₽. Авторизация, один основной сценарий, push-уведомления, публикация. Задача такого приложения — проверить, будут ли им вообще пользоваться, до того как вкладываться дальше.

Рабочий продукт — 500 000 – 1 200 000 ₽. Личный кабинет, оплата, история заказов, программа лояльности, админка для вашей команды.

Платформа — от 1 500 000 ₽. Маркетплейс с продавцами и покупателями, финтех с верификацией личности, всё, где есть деньги пользователей и требования регуляторов.

Нативная разработка или кроссплатформенная

Нативная — отдельный код под iOS и под Android: две команды, два срока, двойная поддержка. Кроссплатформенная (React Native, Flutter) — одна кодовая база на обе платформы.

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

Расходы, которые обычно забывают заложить

  • Аккаунты разработчика. Apple — 99 $ в год, Google Play — 25 $ разово. Без них приложение не опубликовать.
  • Сервер. Приложение почти всегда требует бэкенда, а это ежемесячный платёж, а не разовый.
  • Обновления под новые версии ОС. Apple и Google каждый год меняют требования. Приложение, которое год не трогали, рискует вылететь из стора.
  • Первый месяц после релиза. Всегда всплывают сценарии, которых не было в тестах. Это нормально и это стоит денег.

На чём можно сэкономить, а на чём нельзя

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

Не стоит экономить на проектировании. Переделка экрана на бумаге стоит час, в готовом коде — неделю.

Что дальше

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