Многие предприниматели считают релиз финальной точкой.
Сделали дизайн.
Разработали приложение.
Опубликовали в App Store и Google Play.
Можно выдыхать.
Но в реальности именно после запуска приложение впервые сталкивается не с тестировщиком, не с дизайнером и не с владельцем бизнеса.
А с обычными пользователями.
Они заходят с разных телефонов.
Нажимают не туда.
Забывают пароль.
Не понимают статус заказа.
Пишут в поддержку.
Бросают оплату.
Жалуются, что не пришло уведомление.
Просят поменять адрес, время, услугу или состав заказа.
И вот здесь становится понятно: релиз — это не конец расходов.
Это начало жизни продукта.
Типовая ситуация
Предприниматель заказывает приложение для бизнеса.
Например, для доставки, записи на услуги, аренды, сервиса или заказов.
На старте всё выглядит понятно:
нужно приложение для клиента,
админка для менеджера,
каталог услуг или товаров,
оплата,
уведомления,
статусы заказов.
Команда делает первую версию.
Приложение открывается.
Основные функции работают.
Проект публикуется.
И дальше в него начинают заходить реальные люди.
Первый клиент не может войти.
Второй оплатил, но менеджер не понял, где это видно.
Третий выбрал неправильный адрес.
Четвёртый не получил push-уведомление.
Пятый написал, что статус “в обработке” ничего не объясняет.
С точки зрения предпринимателя это может выглядеть так:
“Почему это не предусмотрели?”
Но часто проблема не в том, что кто-то плохо сделал приложение.
Проблема в другом.
До старта не разобрали, как система будет жить после релиза.
Главная ошибка: весь бюджет потратили на разработку
Частая ситуация: у бизнеса есть условный бюджет на приложение.
Например, 700 тыс ₽, 1 млн ₽ или 1,5 млн ₽.
Предприниматель хочет вложить всё в разработку. Логика понятная: чем больше функций войдёт в первую версию, тем лучше.
Но это ловушка.
Потому что после запуска почти всегда появляются расходы, которые не были видны на этапе макетов:
нужно исправить сценарий входа;
поменять текст в статусах;
добавить фильтр в админку;
доработать уведомления;
разобраться с оплатой;
обновить приложение;
переделать часть логики заказа;
добавить отчёт для руководителя;
подправить экран, где пользователи чаще всего уходят.
Каждая задача может казаться небольшой.
Но из таких небольших задач быстро собирается отдельный бюджет.
Особенно если приложение связано с деньгами: оплатой, заказами, доставкой, записью, личными кабинетами, бонусами или ролями сотрудников.
Почему проблема не только в разработке
Мобильное приложение — это не просто экран на телефоне.
Для бизнеса это система.
В ней есть клиент.
Менеджер.
Администратор.
Оплата.
Уведомления.
Статусы.
База клиентов.
Иногда CRM, 1С, склад, курьеры, бонусы, рассылки и отчёты.
После релиза начинает проверяться не только код.
Проверяется вся бизнес-логика.
Например:
удобно ли менеджеру обрабатывать заявки;
понятно ли клиенту, что происходит с заказом;
видит ли собственник нужные цифры;
можно ли быстро исправить ошибку;
есть ли доступы к сторам, серверу и аналитике;
понятно ли, кто отвечает за обновления;
заранее ли описано, что входит в гарантию.
Если этого нет, любая мелочь превращается в отдельный спор, отдельную задачу и отдельный счёт.
Что нужно проверить до старта
До разработки важно решить не только “какие экраны делаем”.
Нужно проверить, как приложение будет обслуживаться после запуска.
Минимальный список вопросов:
Кто принимает ошибки от пользователей?
Кто проверяет, что проблема действительно в приложении?
Кто отвечает за сервер, домен, доступы и сторы?
Какие ошибки исправляются в рамках гарантии?
Какие изменения считаются новой доработкой?
Кто обновляет приложение после правок?
Где будут храниться доступы?
Какие метрики смотрим после запуска?
Как быстро нужно реагировать, если сломалась оплата или оформление заказа?
Что делаем, если Apple или Google попросили внести изменения?
Это скучные вопросы.
Но именно они потом экономят деньги.
Потому что после запуска предпринимателю нужно не “разбираться с техническими нюансами”.
Ему нужно, чтобы заявки проходили, клиенты понимали процесс, менеджеры работали без хаоса, а система не тормозила продажи.
Какой MVP логичен в первой версии
Первая версия не должна быть огромной.
Но она должна быть готова к реальным пользователям.
Для MVP обычно достаточно:
простой регистрации или входа;
ключевого сценария заказа, записи или заявки;
админки для обработки обращений;
понятных статусов;
минимальных уведомлений;
базовой аналитики;
понятного процесса оплаты, если она нужна;
сбора ошибок и обратной связи;
доступов, оформленных на клиента;
плана поддержки после релиза.
Главная задача MVP — не удивить количеством функций.
Главная задача — проверить, работает ли бизнес-сценарий.
Заходит ли клиент.
Оставляет ли заявку.
Оплачивает ли.
Возвращается ли.
Удобно ли менеджеру работать.
Видит ли собственник, что происходит.
Если это не проверить, можно полгода дорабатывать красивое приложение, которое не помогает бизнесу зарабатывать.
Что лучше отложить
В первую версию часто пытаются добавить всё:
сложную бонусную систему;
много ролей;
реферальную программу;
несколько видов подписок;
чат;
внутреннюю валюту;
личные кабинеты для всех типов пользователей;
сложные отчёты;
интеграции “на будущее”.
Часть этих функций может быть полезна.
Но не всегда на старте.
Если приложение ещё не проверило базовый сценарий, лишние функции только увеличивают бюджет и усложняют поддержку.
Сначала лучше запустить ядро:
клиент оставляет заявку или заказ;
бизнес получает и обрабатывает;
клиент понимает статус;
собственник видит результат;
команда собирает обратную связь.
После этого уже видно, что действительно нужно развивать.
Где обычно растёт бюджет после запуска
Бюджет чаще всего растёт не из-за одной большой ошибки.
Он растёт из мелочей.
Например:
в админке не хватает нужного фильтра;
менеджер не видит важное поле;
клиент не понимает, что делать после оплаты;
уведомления приходят не в тот момент;
нужно поменять логику статусов;
появились новые условия доставки;
нужен отчёт по заказам;
понадобилось обновление из-за требований стора;
пользователи массово задают один и тот же вопрос;
оказалось, что часть сценария удобна владельцу, но неудобна клиенту.
Именно поэтому поддержку нужно считать заранее.
Не как “лишний расход”.
А как часть запуска.
Приложение без поддержки похоже на магазин без администратора. Формально он открыт. Но когда появляются клиенты, вопросы и проблемы, некому быстро навести порядок.
Практический вывод
Перед разработкой нужно считать не только стоимость первой версии.
Нужно считать весь запуск.
Разработка.
Публикация.
Первые пользователи.
Ошибки.
Гарантия.
Доработки.
Аналитика.
Обновления.
Поддержка.
Если этого не сделать, приложение может быть опубликовано, но быстро начать съедать деньги.
Не потому что идея плохая.
А потому что бизнес не подготовился к жизни после релиза.
Хороший запуск — это не момент, когда приложение появилось в сторе.
Хороший запуск — это когда первые пользователи смогли пройти нужный сценарий, менеджеры смогли обработать заявки, а предприниматель понял, что нужно улучшать дальше.
Если вы думаете о мобильном приложении для бизнеса, лучше сначала проверить бизнес-логику, MVP, бюджет, интеграции и риски.
Иногда бизнесу действительно нужно приложение.
Иногда дешевле и быстрее начать с Mini App, CRM, бота или простой системы заявок.
В «САП КОД» мы перед разработкой разбираем, что должно войти в первую версию, что лучше отложить, где после запуска могут появиться расходы и как не превратить поддержку в бесконечные доработки.
Оставить заявку на разбор проекта можно здесь.