Предприниматель хочет запустить приложение.
Он отправляет одну и ту же задачу в несколько компаний и получает три коммерческих предложения.
Первая компания считает проект в 1,4 млн ₽.
Вторая — в 1,1 млн ₽.
Третья говорит: “Сделаем за 580 тысяч”.
На первый взгляд выбор очевиден.
Зачем платить почти в два раза больше, если везде написано примерно одно и то же?
Каталог.
Корзина.
Оплата.
Личный кабинет.
Уведомления.
Админка.
Публикация.
Но в разработке приложения опасность часто не в самой цене.
Опасность в том, что предприниматель сравнивает строки в КП, а не реальный объём запуска.
Типовая ситуация
Предприниматель приходит с задачей.
Ему нужно приложение для доставки, записи, заказов, аренды, сервиса или внутренней автоматизации.
Он не обязан разбираться в разработке.
Он смотрит как собственник бизнеса.
Есть задача.
Есть список функций.
Есть цена.
Есть сроки.
И если одно КП дешевле на 500–800 тысяч рублей, рука сама тянется выбрать его.
Это нормально. Деньги считать надо.
Но вопрос не в том, кто дешевле.
Вопрос в другом: что именно входит в эту цену и что всплывёт после подписания договора.
Где начинается ошибка
Допустим, в КП написано: “интеграция оплаты”.
Для предпринимателя это звучит просто.
Клиент выбрал товар.
Нажал кнопку.
Деньги списались.
Заказ создался.
Но на практике оплата — это не одна кнопка.
Нужно понять:
- что происходит, если платёж не прошёл;
- как заказ получает статус “оплачен”;
- нужны ли возвраты;
- кто видит ошибку оплаты;
- куда приходит уведомление;
- что делать, если деньги списались, а заказ не создался;
- какие данные должны уйти в админку;
- нужна ли связь с CRM, 1С или кассой.
Если это не разобрали заранее, позже появляется фраза:
“Это не входило в оценку”.
И предприниматель оказывается перед выбором.
Или доплачивать.
Или запускать продукт с дырой в логике.
Оба варианта плохие.
Почему одинаковый список функций ничего не доказывает
В трёх КП может быть написано одно и то же слово: “админка”.
Но внутри это могут быть три разных продукта.
В дешёвом варианте админка может быть простой таблицей заявок.
Заявка пришла.
Менеджер увидел.
Статус поменял.
Для некоторых MVP этого достаточно.
Но если у бизнеса есть товары, цены, категории, сотрудники, статусы, акции, уведомления, роли пользователей и разные сценарии заказов, простая таблица быстро превращается в проблему.
Без нормальной админки предприниматель не управляет приложением.
Он зависит от разработчиков по мелочам:
“Поменяйте цену”.
“Добавьте категорию”.
“Скройте товар”.
“Исправьте статус”.
“Добавьте сотрудника”.
“Измените текст уведомления”.
Каждая такая мелочь — время, деньги и нервная переписка.
И тут дешёвое КП начинает дорожать.
Не потому что подрядчик обязательно плохой.
А потому что на старте не разобрали, какая админка нужна бизнесу.
Публикация тоже может стать сюрпризом
В КП часто пишут: “публикация входит”.
Звучит хорошо.
Но что именно входит?
Создание аккаунтов разработчика?
Подготовка скриншотов?
Описание приложения?
Политика конфиденциальности?
Настройка прав?
Ответы на замечания App Store или Google Play?
Исправление технических замечаний?
Повторная отправка на проверку?
Публикация — это не просто нажать кнопку.
Площадки могут вернуть приложение с замечаниями.
Иногда нужно править тексты.
Иногда — экраны.
Иногда — логику авторизации, оплату или работу с данными.
Модерацию App Store и Google Play никто не может гарантировать.
Но можно заранее договориться, кто и в каком объёме помогает пройти этот этап.
Если этого нет в договорённостях, появляется риск:
приложение технически готово,
деньги потрачены,
а пользователи его пока не видят.
Низкая цена — не всегда плохо
Важно не путать.
Дешёвое предложение само по себе не является проблемой.
Иногда это нормальный вариант.
Например, команда честно говорит:
“Мы делаем только MVP”.
“Берём готовые решения”.
“Не делаем сложную админку на первом этапе”.
“Интеграции переносим на вторую версию”.
“Публикация входит только в базовой помощи”.
“Вот список того, что не входит”.
Это честный подход.
Он может быть хорошим решением для бизнеса, если нужно быстро проверить гипотезу и не тратить лишнее.
Проблема начинается там, где цена низкая, а границы проекта размыты.
Как дешёвое КП превращается в дорогое
Сначала предприниматель радуется.
Вместо 1,4 млн ₽ он подписывает договор на 580 тысяч ₽.
Потом начинается разработка.
И выясняется:
- возвраты оплаты не заложены;
- роли пользователей не продуманы;
- админка слишком простая;
- уведомления нужны не только клиенту, но и менеджеру;
- часть экранов не была учтена;
- статусы заказов работают не так, как в бизнесе;
- интеграция с CRM не входит;
- тестирование ограничено;
- публикация описана слишком общо;
- исходники и доступы надо отдельно уточнять.
Дальше идут доплаты.
50 тысяч.
80 тысяч.
120 тысяч.
Ещё один этап.
Ещё две недели.
Ещё согласование.
В итоге проект за 580 тысяч ₽ может приблизиться к 1,2–1,5 млн ₽.
Только с разницей.
В дорогом КП это могло быть заранее разобрано и заложено.
А в дешёвом варианте предприниматель приходит к этой сумме через задержки, споры и переделки.
Почему проблема не только в разработке
Мобильное приложение для бизнеса — это не набор экранов.
Это рабочая система.
В ней должны совпасть:
- клиентский сценарий;
- логика заказа или записи;
- админка;
- роли сотрудников;
- оплата;
- уведомления;
- интеграции;
- данные;
- поддержка;
- публикация;
- права на исходники и аккаунты.
Если бизнес-логику не разобрать до старта, разработчики всё равно начнут принимать решения.
Только уже по ходу проекта.
И не факт, что эти решения будут удобны бизнесу.
Например, клиент оформляет заказ, но менеджер не понимает, откуда он пришёл.
Оплата прошла, но статус не обновился.
Заявка есть, но уведомление не дошло.
Товар закончился, но в приложении он ещё продаётся.
Пользователь удалил заказ, а в админке остался мусор.
Это не “мелочи”.
Это то, из-за чего приложение после запуска не помогает бизнесу, а создаёт новую ручную работу.
Что надо проверить до подписания договора
Перед выбором подрядчика стоит проверить не только цену.
Нужно пройтись по семи вопросам.
Первое. Что входит в MVP первой версии?
Не “всё приложение”, а именно первая рабочая версия.
Какие функции нужны для запуска, а какие можно отложить.
Второе. Какая админка входит?
Можно ли управлять товарами, услугами, ценами, заказами, пользователями и статусами без разработчиков.
Третье. Как описана оплата?
Есть ли ошибки платежей, статусы, возвраты, уведомления, связь с заказом.
Четвёртое. Какие интеграции входят?
CRM, 1С, касса, склад, SMS, push-уведомления, карты, службы доставки.
Каждая интеграция может сильно влиять на бюджет.
Пятое. Кто тестирует продукт?
Если тестирование не заложено, ошибки будут искать первые пользователи.
Для бизнеса это плохо.
Шестое. Что входит в публикацию?
Нужны аккаунты клиента, тексты, скриншоты, политика конфиденциальности, помощь с замечаниями стора.
Седьмое. Кому принадлежат исходники и доступы?
Аккаунты App Store и Google Play лучше оформлять на клиента.
Права и исходники тоже нужно фиксировать заранее.
Какой MVP логичен в первой версии
Не всегда нужно делать большое приложение сразу.
Для первой версии часто достаточно:
- личного кабинета клиента;
- оформления заказа или записи;
- базовой оплаты или заявки на оплату;
- статусов;
- уведомлений;
- простой, но рабочей админки;
- минимальной аналитики;
- базовой публикации;
- понятной поддержки после запуска.
Главная цель MVP — проверить, что люди действительно пользуются продуктом, а бизнес может обрабатывать заявки без хаоса.
Всё остальное можно развивать дальше.
Что лучше отложить
На старте часто можно не делать:
- сложную систему бонусов;
- внутренний чат;
- маркетплейс на 10 ролей;
- продвинутую аналитику;
- многоуровневую систему прав;
- десятки интеграций;
- красивую, но ненужную анимацию;
- отдельные приложения для всех ролей.
Эти вещи могут быть полезны.
Но не всегда в первой версии.
Если добавить всё сразу, бюджет растёт, сроки растут, а запуск откладывается.
Иногда бизнесу выгоднее выйти проще, но быстрее.
Где обычно растёт бюджет
Бюджет чаще всего растёт не из-за “ещё одного экрана”.
Он растёт из-за неразобранной логики.
Например:
- оказалось, что заказ проходит 6 статусов, а не 2;
- у менеджера и администратора разные права;
- товар может быть в наличии, под заказ и недоступен;
- оплата должна поддерживать возвраты;
- нужна интеграция с CRM;
- push-уведомлений мало, нужны SMS;
- данные надо выгружать в Excel;
- клиент хочет видеть историю заказов;
- владелец хочет отчёты по выручке и заявкам.
Всё это нормальные бизнес-задачи.
Но они должны быть известны до оценки.
Иначе КП получается красивым, но неполным.
Практический вывод
Самое опасное коммерческое предложение — не самое дорогое.
Самое опасное — непонятное.
Когда сумма есть.
Список функций есть.
Сроки есть.
А границ проекта нет.
Низкая цена может быть хорошим решением, если честно понятно, что входит в MVP, а что остаётся на потом.
Но если дешёвое КП обещает “всё под ключ” без разбора бизнес-логики, админки, интеграций, оплаты, публикации и прав — экономия может быстро закончиться.
Перед выбором подрядчика нужно сравнивать не только цену.
Нужно сравнивать объём запуска.
Потому что бизнес платит не за список слов в КП.
Бизнес платит за работающую систему, которая принимает заявки, помогает сотрудникам, не ломает процессы и может развиваться дальше.
Если вы думаете о мобильном приложении для бизнеса, лучше сначала проверить бизнес-логику, MVP, бюджет, интеграции и риски.
Иногда бизнесу действительно нужно приложение.
Иногда дешевле и быстрее начать с Mini App, CRM, бота или простой системы заявок.
В «САП КОД» мы перед разработкой разбираем проект: что должно войти в первую версию, где могут появиться доплаты, какие интеграции нужны, какую админку делать и что лучше отложить.
Оставить заявку на разбор проекта можно здесь