У словосочетания «мобильное приложение для бизнеса» нет типового состава. За ним может стоять экран с каталогом и кнопкой «позвонить», а может — личный кабинет с оплатой, расписанием и связкой с учётной системой. Разница в работе больше, чем разница в названии.
Отсюда и разнобой в названиях: разработка бизнес-приложений, корпоративное приложение, приложение для компании — за всеми стоит одна и та же работа, и ориентироваться надо на её состав, а не на формулировку в объявлении.
Поэтому вопрос «сколько стоит» без описания сценариев не имеет ответа. Разработка мобильных приложений для бизнеса начинается не с платформ и не с бюджета, а с описания того, что человек будет делать внутри. Ниже — с этого конца: какие сценарии приложение закрывает на самом деле, с чем оно связывается, что входит в стоимость и что считается отдельно.
Разговор про то, нужно ли приложение вообще и чем клиента возвращают дешевле, — в отдельной статье. Здесь считаем, что решение уже принято.
Сценарии удержания: что приложение делает конкретно
Не свойства («удобно», «быстро»), а действия, которые человек повторяет.
Повторить прошлый заказ или запись в пару касаний. Понятный сценарий: данные прошлого заказа уже сохранены, поэтому человеку не приходится заново проходить весь путь оформления. У приложения для записи на занятия, которое я делал, это выглядит так: детали занятия и запись — на одном экране, тренер, время и стоимость видны сразу.
Абонемент, баланс, остаток. Сколько занятий осталось, до какого числа действует, когда списалось. Так у приложения появляется полезный сценарий и между покупками, а не только в момент оплаты.
Напоминание о следующем шаге. Не рассылка, а сообщение, привязанное к состоянию: запись завтра, абонемент заканчивается, заказ готов к выдаче. Работает при одном условии — человек разрешил уведомления.
История и статус. Что заказывал, что сейчас происходит, когда будет. Человек может посмотреть это сам, не обращаясь за информацией к менеджеру.
Оплата сохранённым способом. Не «принимаем карты», а отсутствие шага, на котором человек уходит искать карту в кошельке.
Обратите внимание: все пять — про повторяющееся действие. Если у вашего клиента такого действия нет, приложение будет работать как красивый каталог, и удержания от него ждать не стоит.
С чем приложение связывается
Одна строка «интеграция» может скрывать очень разный объём работы.
Действующая CRM или ваша серверная часть. Обращения, заказы и записи из приложения попадают туда, где вы уже работаете. Это входит в стоимость — при условии, что система есть и у неё есть интерфейс для подключения.
Приём платежей. Оплата внутри приложения, сохранённые способы, возвраты. У площадок есть свои правила для покупок внутри приложения — их состав уточняется под конкретный продукт.
Расписание или календарь. Для записи и бронирования — синхронизация свободного времени. Здесь связь двусторонняя: приложение и показывает время, и занимает его, а значит, нужно решить, чья версия верна при одновременных изменениях.
Push-уведомления. Нужна отдельная настройка доставки и логики: кому, когда и по какому событию отправлять сообщение.
О том, как устроена передача данных между системами и чем односторонняя связь отличается от двусторонней, я писал в разборе интеграций — там же вопросы, которые стоит задать подрядчику.
Что входит в разработку мобильного приложения для бизнеса
Состав полноценного продукта для двух платформ — то, что вы получаете за нижнюю границу в 950 000 ₽:
- Разбор задачи, сценариев и ролей — до всякого дизайна.
- Проектирование структуры и пути пользователя.
- Дизайн экранов под iOS и Android.
- Разработка кроссплатформенного приложения — одна база кода на две платформы.
- Личный кабинет, записи или заказы — тот самый повторяющийся сценарий.
- Интеграция с действующей CRM или серверной частью.
- Тестирование на реальных устройствах, а не только в эмуляторе.
- Подготовка к публикации в App Store и Google Play.
Это нижняя граница, а не фиксированная цена. Что двигает сумму вверх внутри формата — число ролей, объём сценариев, требования к данным — разбирал отдельно.
Что оценивается отдельно
Три вещи, которых в этой сумме нет, — и их лучше узнать сейчас, а не на второй встрече.
Создание серверной части и админ-панели с нуля. Если системы, в которую приложение будет складывать данные, ещё не существует, её нужно построить. Это отдельный продукт со своим объёмом.
Нестандартная бизнес-логика. Сложные правила расчёта, свои алгоритмы подбора, нетиповые сценарии оплаты.
Сложные интеграции и перенос данных. Отраслевые системы, 1С, миграция из старого решения.
Плюс то, что появляется после запуска и не относится к разработке вовсе: аккаунты разработчика, инфраструктура, тарифы сторонних сервисов, обновления под новые версии систем. Это отдельная строка бюджета, и обсуждать её лучше до подписания, а не в первом счёте после релиза.
Роли: кто ещё работает с приложением
В разработке бизнес-приложений это второй источник объёма после сценариев, и его легко пропустить при обсуждении экранов клиента: кто будет работать с данными на другой стороне.
Сначала удобно описать клиентский сценарий. Но дальше нужно решить, кто будет видеть заказы, подтверждать записи, менять расписание и работать с сообщениями. Здесь развилка, и от неё зависит бюджет.
Роль остаётся в вашей действующей системе. Если менеджер продолжает работать в уже существующей CRM, отдельный интерфейс для него разрабатывать не требуется. В описанном выше составе такая интеграция предусмотрена.
Роль требует своего экрана. Администратор подтверждает записи прямо в приложении, курьер отмечает выдачу, тренер видит список на занятие. Для такой роли появляются свои экраны, права доступа, состояния и сценарии — всё это добавляется к клиентской части.
Роль требует админ-панели. Отдельный интерфейс управления каталогом, ценами и пользователями. Он относится к строке «оценивается отдельно», если такой панели у вас ещё нет.
Практический вывод: перед разговором о бюджете полезно перечислить не только экраны клиента, но и всех, кто будет работать с данными приложения, — и напротив каждого написать, где именно он работает сейчас.
Почему я не называю точный срок
На странице приложений вместо срока написано «точные сроки и бюджет — после разбора задачи», и это не уклончивость.
Срок приложения зависит от числа ролей, количества интеграций и требований к данным конкретной задачи. Поэтому одинаковое число экранов ещё не означает одинаковый срок: роли, интеграции и требования к данным добавляют отдельный объём работы.
Названный наугад срок будет ровно таким же «точным», как сумма, посчитанная по трём предложениям. Ориентир я даю после разбора — и он привязан к этапам, а не к одной дате.
Когда 950 000 — не ваш вариант
Скажу это до формы, а не после: прежде чем заказать мобильное приложение для бизнеса, стоит проверить три вещи.
Если гипотеза не проверена. Вы предполагаете, что люди будут пользоваться, но данных нет. Тогда можно сначала ограничить первую версию одним ключевым сценарием и не включать всё остальное: такая версия позволяет получить реальные данные о поведении пользователей до вложения в полноценный продукт. Что в неё входит и сколько она стоит — в разборе MVP.
Если пользователи работают в основном за компьютером. Для сотрудников, партнёров или клиентов, работающих с вами в рабочее время, стоит сначала сравнить мобильное приложение с веб-кабинетом: для части таких задач отдельное приложение для iOS и Android может оказаться лишним.
Если повторяющегося действия нет. Приложение вокруг разовой покупки обосновать заметно сложнее, чем вокруг записи, заказа или продления.
С чего начать разговор
Если вы собираетесь заказать мобильное приложение для бизнеса, начинать стоит не с бюджета и не с платформ, а со сценария: что человек делает в приложении от первого открытия до результата и как часто он это повторяет. По такому описанию уже можно разбирать состав: какие роли нужны, какие интеграции появятся и что попадёт в базовую часть, а что придётся оценивать отдельно.
Состав, стоимость и то, что считается отдельно, — на странице мобильных приложений. Там же форма: пришлите сценарий, и я отвечу, из чего соберётся ваш состав и какие интеграции в него попадут.