Рубрика: Мобильные приложения

Приложение вышло в магазин, пользователи начали им пользоваться, а в бюджете осталась одна строка: «поддержка». Что в ней учитывать — исправление ошибок, новые функции, серверы, выпуск обновлений? И означает ли оплаченный пакет часов, что команда подключится ночью, если перестанут проходить заказы?

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

Я занимаюсь разработкой в Mobecan. На нашей странице поддержки приложений указан минимальный пакет 30 часов: стоимость зависит от состава специалистов. Ниже покажу, как разобрать такую оценку и какие расходы проверить до старта. Условия услуги проверены 20 сентября 2026 года.

За что вы платите после запуска

Удобно разделить бюджет на три части. Первая — сохранить работоспособность существующего продукта. Вторая — изменить его возможности. Третья — оплачивать сервисы, от которых он зависит.

Статья расходов	Что уточнить в предложении
Диагностика и исправление ошибок	Включены ли воспроизведение проблемы, поиск причины и проверка исправления
Совместимость и зависимости	Какие устройства и версии ОС проверяются; какие обновления библиотек запланированы
Тестирование и выпуск	Кто проверяет связанные сценарии, готовит сборку и сопровождает релиз
Новые функции	Есть ли отдельная оценка; сколько часов остается на текущие проблемы
Серверная часть и инфраструктура	Кто отвечает за API, базы данных, резервные копии и мониторинг
Внешние сервисы	Кто оплачивает хостинг, СМС, другие платные интеграции и аккаунты магазинов
Работа с инцидентами	В какие часы команда доступна и что происходит при аварии вне этого времени

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

Как посчитать пакет из 30 часов

Если все работы оплачиваются по одной согласованной ставке, расчет простой: 30 часов × ставка за час. Если ставки зависят от роли, нужно сложить стоимость работы каждого специалиста.

Например, для объяснения расчета возьмем условное распределение: 18 часов разработки, 8 часов тестирования и 4 часа на координацию и подготовку выпуска. Всего 30 часов. Это учебный пример, не типовой состав пакета Mobecan и не обещание выполнить любой набор задач за это время. В реальной оценке выпуск могут учитывать в часах разработчика, а состав ролей будет другим.

Стоимость такого примера = 18 × ставка разработчика + 8 × ставка тестировщика + 4 × ставка координатора. Умножать все часы на самую низкую ставку из предложения неправильно, если задачи выполняют разные специалисты.

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

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

Почему первый месяц может стоить дороже

Когда проект принимает новая команда, часть времени уходит на знакомство: проверить исходники, воспроизвести сборку, разобраться в интеграциях и понять, как выпускались обновления.

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

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

Если проект давно не обновлялся, команда может обнаружить дополнительные препятствия. Но необходимость восстановить сборку еще не доказывает, что приложение нужно переписать. Сначала стоит выяснить причину и оценить варианты.

Почему «маленькая правка» требует тестирования

Представим приложение доставки: после изменения корзины нужно проверить не только итоговую сумму на экране, но и передачу заказа, применение бонусов и связанные сценарии оплаты. Это пример проверки, а не описание конкретного инцидента клиента.

В разработанном нами приложении «Вкус и Лосось» есть корзина, бонусная программа, авторизация и уведомления о статусах заказа. Публичный кейс показывает, сколько связанных сценариев может быть у продукта. Бюджет его сопровождения здесь не приводится.

Поэтому сравнивать предложения только по часам написания кода неудобно. У одного подрядчика проверка и выпуск уже учтены, у другого появятся отдельной строкой. Попросите оценить весь путь задачи: диагностику, изменение, проверку и доставку обновления пользователям.

Пакет часов, работа по задачам или выделенная команда

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

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

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

Ни одна модель не заменяет договоренности о приоритетах, приемке и авариях. Для сравнения попросите исполнителей оценить один и тот же список задач при одинаковом режиме работы.

Что означает SLA и за что здесь платить

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

Время реакции — это начало обработки обращения. Время восстановления — момент, когда согласованный сервис снова работает. Окончательное исправление причины может потребовать отдельной работы. Эти сроки не стоит смешивать в одно обещание «решаем за час».

Если вам нужна доступность вечером и в выходные, включите ее в запрос на оценку. Согласуйте критичные сценарии, каналы уведомления, ответственных и временные меры. Обычный пакет разработки не дает оснований рассчитывать на дежурство 24/7.

Как снизить расходы без потери контроля

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

Разделяйте обязательные исправления и пожелания. Если в одном списке стоят сбой авторизации и новый цвет кнопки, часы легко потратить без заметного улучшения работы продукта.

По плановым изменениям обсуждайте объединение в релизы: это позволяет не повторять одну и ту же подготовку для каждой мелкой задачи. Критичные исправления при этом не нужно задерживать ради удобного графика.

Проверяйте отчет вместе с результатом: что изменилось, что проверено, что выпущено, какие вопросы остались. Одного перечня списанных часов недостаточно, чтобы понимать состояние приложения.

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

Что отправить для оценки поддержки

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

Попросите показать в ответе:

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

В Mobecan рассматриваем нативные приложения iOS и Android и проекты на Flutter, в том числе после другой команды. Минимальный пакет — 30 часов; состав задач и стоимость согласуем после знакомства с проектом.

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

Приложение работает, но договориться о следующем релизе все сложнее. Исправления затягиваются, оценки непонятны или команда больше не может заниматься проектом. Вы находите другого разработчика — и выясняется, что ссылки на Git недостаточно для продолжения работы.

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

Ниже — порядок, который я рекомендую использовать заказчику при смене команды. Это чек-лист организации передачи, а не история конкретного перехода клиента Mobecan.

Сначала определите, что именно вы передаете

Смена подрядчика не обязательно означает перенос серверов, смену аккаунтов в магазинах или переписывание приложения. Если инфраструктура и аккаунты принадлежат вашей компании, новой команде может быть достаточно отдельных доступов с нужными ролями.

Разделите три задачи: передать сопровождение, устранить накопленные проблемы и развивать продукт. Если смешать их в одну оценку, трудно понять, за что вы платите и в какой момент новая команда принимает ответственность.

На первой встрече зафиксируйте:

• Какие версии приложения опубликованы и какая версия исходников им соответствует.
• Что сейчас не работает и какие обращения пользователей остаются открытыми.
• Какие ближайшие изменения обязательны, а какие можно отложить.
• Кто исправляет аварии, пока новая команда знакомится с проектом.
• Как вы поймете, что приемка завершена.

Что запросить у действующей команды

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

Что передать	Что должна проверить новая команда
Репозитории мобильного приложения и серверной части	Есть история изменений, отмечена версия последнего релиза, доступны все необходимые зависимости
Инструкция по сборке	Приложение собирается на новом рабочем месте, а не только на ноутбуке прежнего разработчика
Аккаунты магазинов приложений	Назначенные роли позволяют выполнять нужные действия; понятны владелец и порядок выпуска обновлений
Подпись приложения и процесс релиза	Есть рабочий способ подписать и загрузить следующую сборку, определены ответственные за ключи и сертификаты
Серверы, домены, DNS, базы данных	Известны владельцы, платежи, окружения, зависимости и порядок восстановления
Интеграции	Понятно, кто отвечает за авторизацию, оплату, СМС, push, CRM и другие подключенные сервисы
Дизайн и продуктовая документация	Доступны исходные макеты, правила поведения экранов и согласованные требования
Мониторинг и аналитика	Новая команда видит ошибки, важные события и может отличить сбой от обычного поведения
Список задач и известных дефектов	Зафиксированы приоритеты и ограничения, которые нельзя принять за новые ошибки подрядчика

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

Почему передача только мобильного кода не решает задачу

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

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

Это не описание смены подрядчика в «Вкус и Лосось»: публичный кейс здесь иллюстрирует состав системы, который необходимо учитывать при сопровождении.

Проведите контрольную сборку и проверку сценариев

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

Попросите новую команду собрать приложение из переданного репозитория в подготовленном окружении и установить тестовую версию. Результат стоит зафиксировать: версия кода, настройки окружения, найденные препятствия и способ их устранения.

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

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

После сборки нужен небольшой контролируемый выпуск. Изменение может быть минимальным, но команда должна пройти весь путь до доставки обновления: подготовка, проверка, загрузка, согласование и наблюдение после выпуска. Доступ к исходникам сам по себе этого не подтверждает.

Аккаунт магазина и подрядчик — разные вещи

Если аккаунт разработчика остается у вашей компании, не нужно автоматически переносить приложение в аккаунт нового исполнителя. Сначала проверьте, можно ли решить задачу назначением ролей.

Когда действительно меняется аккаунт владельца приложения, применяется отдельная процедура магазина. У Apple это перенос приложения в App Store Connect, у Google — перенос между аккаунтами разработчиков. Требования и связанные сервисы проверяют перед переносом: передача репозитория не заменяет эти процедуры.

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

Переключайте ответственность поэтапно

Сначала подтвердите доступы и работоспособность тестового окружения. Затем согласуйте первый выпуск и план возврата к рабочему состоянию. Только после приемки отключайте ненужные доступы прежней команды и меняйте использовавшиеся совместно секреты по согласованному плану.

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

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

Нужно ли переписывать приложение

Смена команды сама по себе не является основанием для переписывания. Сначала нужна диагностика: что мешает сборке и выпуску, где возникают сбои, какие части сложно менять и почему.

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

Если исходники не собираются, это еще не доказательство необходимости полной переделки. Причиной могут быть отсутствующие настройки, зависимости или доступы. Сначала нужно отделить нехватку материалов от проблем архитектуры.

Как оценивать стоимость передачи

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

Обоснованная оценка объясняет, что команда уже проверила, каких данных не хватает и какие допущения использует. Универсальная цена за «приемку любого приложения» без знакомства с проектом мало говорит о конечном объеме работ.

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

Чек-лист перед завершением передачи

• У компании есть контроль над репозиториями, инфраструктурой и аккаунтами магазинов.
• Новая команда воспроизвела сборку опубликованной версии или зафиксировала и объяснила отличия.
• Основные пользовательские сценарии проверены, известные дефекты перечислены.
• Подтверждены резервное копирование и способ восстановления; для критичных данных проведена проверка восстановления в изолированной среде.
• Пройден согласованный процесс выпуска обновления, определены ограничения отката.
• Настроены наблюдение за ошибками и канал для инцидентов.
• Есть список оставшихся рисков, ответственные и очередность работ.
• Завершена передача ответственности и пересмотрены доступы.

Если несколько пунктов остаются неподтвержденными, передачу лучше считать незавершенной и явно описать, кто закрывает эти пробелы.

Если вы планируете сменить команду

Начать разговор с Mobecan можно со ссылок на приложение в магазинах, описания текущей проблемы и ближайших задач. Пароли, исходники и данные пользователей в первом сообщении не нужны.

Обсудить передачу приложения команде Mobecan. Определим, какие материалы нужны для оценки и что проверить перед началом сопровождения.

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

Скачать реестр передачи приложения

Заполните владельцев, ответственных, сроки и результаты проверок в Excel или другой программе для таблиц. Пароли, ключи и персональные данные в таблицу не вносите.

Скачать чек-лист передачи приложения (CSV)

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

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

Я Роман Кузнецов, представляю команду Mobecan. Мы разрабатываем мобильные приложения, в том числе для доставки еды. Ниже — мой подход к выбору: с какими вопросами идти к поставщику готового решения и в какой момент обсуждать собственную разработку.

Когда ресторану подходит готовое приложение для доставки еды

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

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

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

Собственное приложение не создает аудиторию автоматически. Если привлечение гостей и повторные продажи пока не продуманы, дорогая разработка не решит эту задачу сама по себе.

Когда нужна разработка приложения на заказ

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

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

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

Я бы попросил обе стороны — поставщика платформы и разработчика — показать, как они решат одну и ту же задачу. Тогда сравнивать можно будет состав работ и результат.

Готовое приложение и своя разработка: что сравнивать

Критерий	Готовая платформа	Разработка на заказ
Запуск	Может быть быстрее, если достаточно настройки и поддерживаемых интеграций	Срок зависит от проектирования, разработки, проверок и публикации
Сценарии заказа	В пределах настроек платформы и доступных доработок	Можно спроектировать под процессы бизнеса; каждое усложнение влияет на объем работ
Интеграции	Нужно проверить конкретные операции, а не только название учетной системы	Можно разработать необходимый обмен, если внешняя система предоставляет нужный доступ
Расходы	Подключение, подписка, дополнительные модули, доработки и другие платежи по условиям поставщика	Создание продукта, инфраструктура, поддержка и дальнейшее развитие
Изменения	Зависят от возможностей и приоритетов поставщика	Зависят от бюджета, команды и качества существующего кода
Переход к другой команде	Важны условия экспорта данных и доступ к интеграциям	Важны передача кода, документации, доступов и возможность независимой поддержки

Название подхода не гарантирует ни низкую стоимость, ни независимость. Эти свойства нужно проверять в конкретном предложении.

Как проверить готовое приложение: пять сценариев заказа

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

1. Блюдо закончилось после добавления в корзину. Когда гость узнает об этом и сможет ли продолжить заказ без звонка оператора?
2. Адрес находится на границе зон доставки. Какая кухня получит заказ, какой будет стоимость доставки и что произойдет при смене адреса?
3. Оплата прошла, но учетная система временно недоступна. Где будет виден заказ, кто получит уведомление и как исключить потерю или дублирование?
4. Гость хочет использовать бонусы и промокод. Какие правила сработают и одинаково ли их понимают приложение и учетная система?
5. Нужно отменить оплаченный заказ. Как сотрудник выполнит действие, какие статусы увидят остальные системы и что узнает клиент?

Ответ «у нас есть интеграция» еще не описывает поведение системы в этих ситуациях. Попросите показать результат или зафиксировать, какая доработка потребуется. Это поможет обнаружить расходы, которых нет в первоначальной цене.

Что показывает наш проект «Вкус и Лосось»

В Mobecan мы разработали приложение для доставки и самовывоза «Вкус и Лосось». В публичном кейсе описаны меню, оформление заказа, вход через Telegram или СМС, уведомления о статусах, бонусная программа и возможность поделиться собранной корзиной. Посмотреть приложение и разбор проекта.

Экраны из публичного кейса Mobecan. Показаны интерфейсы проекта; цены и акции на экранах относятся к моменту подготовки кейса.

Сохранить работающую программу лояльности

В нашем кейсе на Workspace есть важная деталь: программа «Вкускоины» уже работала до создания нового приложения. Задача состояла в том, чтобы встроить ее в новый пользовательский путь: показать баланс, объяснить начисление и дать возможность использовать бонусы при заказе.

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

Сначала договориться о пути заказа

Команда Mobecan вместе с командой клиента исследовала аудиторию и проработала сценарии от первого экрана до оформления заказа. В кейсе опубликована схема, связывающая меню, доставку и самовывоз, профиль, корзину и оплату.

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

Какие результаты опубликованы в кейсе

По данным кейса, за первые два месяца после релиза количество добавлений в корзину выросло с 1 805 до 3 717, а число активных аккаунтов — с 2 352 до 8 303. Источник этих показателей — публикация Mobecan на Workspace, раздел «Результат».

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

Как сравнить стоимость приложения для доставки еды

Сравнивать цену разработки с месячной подпиской неудобно: это расходы за разные периоды и разный состав работ. Я бы запросил у обеих сторон расчет на одинаковый срок, например на два года, с одними и теми же требованиями.

В расчет стоит включить:

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

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

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

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

Что включить в первую версию

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

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

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

Частые вопросы перед заказом приложения

Можно ли сначала запустить готовое приложение, а потом перейти на свое?

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

Нужна ли ресторану разработка приложения, если уже есть сайт?

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

Если посетителям прежде всего не хватает ответов на вопросы о доставке и условиях заказа, это отдельный сценарий. В нашем продукте Ассист24 есть разбор выбора первого сценария для чат-бота на сайте. Такой помощник не заменяет корзину, оплату и передачу заказа в учетную систему.

Как понять, что готовая платформа не подходит?

Составьте обязательные сценарии и проверьте каждый на демонстрации. Если важный сценарий недоступен, выясните цену и возможность доработки. Решение стоит принимать с учетом этих ограничений, полной стоимости и влияния на работу ресторана.

Обсудим, какой вариант подходит вашей доставке

Если вы выбираете приложение для ресторана или сети, можно начать с короткого описания задачи. Полное техническое задание для первого обращения не обязательно.

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

Обсудим, где можно использовать готовые возможности, какие доработки понадобятся и имеет ли смысл оценивать собственное приложение.

Обсудить приложение с Mobecan — опишите задачу в форме обращения на странице. В сообщении можно указать: «Выбираем между готовым приложением для доставки еды и своей разработкой».