Своё приложение доставки за подписку окупается, когда заказы покрывают расходы

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

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

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

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

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

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

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

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

На /services «Один проект» стоит 250 000 ₽ в месяц, проверено 7 октября 2026. Ниже три условных значения прибавки: это пример расчёта, а не измеренная маржа ресторанов.

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

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

После запуска условно получаем 1 500 заказов в месяц с прибавкой 200 ₽ каждый. На работу сервиса и продвижение уходит 50 000 ₽ в месяц сверх затрат, уже учтённых в прибавке. Считаем две развилки при неизменном потоке заказов.

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

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

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

Открытый покупателем чужой номер заказа тоже часть приёмки. Чужие адрес и состав должны остаться недоступны; работа с адресами покупателей разобрана в статье о персональных данных и ИИ-агентах.

Карту с движущимся курьером можно поставить в следующую очередь. Без неё доставка способна работать; без достоверного назначения и отметки вручения администратор не знает, завершён ли заказ.

Что машина уже умеет собирать? Вход, оплату и анкеты. В кабинете нашего курса появились профиль и вход по почте 8 сентября, анкеты 10 сентября 2026; эти части работают с общими данными ученика.

На /open в срезе 7 октября, 18:57 МСК, было 7 032 коммита за 98 дней. Счётчик показывает изменения основной ветки с 1 июля 2026 без мерж-коммитов. Он не измеряет прибыль клиентов или количество готовых приложений.

Замер 35 минут относится к основанию проекта: с пустой папки до работающего сайта, 19 сентября с 21:13 до 21:48 МСК. За это время не проверяли ресторанное меню, кассу, курьеров и возвраты.

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

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

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

Для доставки добавьте ошибки учётной системы и работу курьера без связи. Если команда создания заказа ещё выполняется, показывать смене готовый заказ рано; в iikoCloud для этого есть отдельное состояние успешного создания.

ЮKassa рекомендует проверять подлинность уведомления, в том числе запросом текущего состояния операции. Надпись об успехе в браузере покупателя не заменяет эту проверку. Ответственность подрядчика и порядок исправления разобраны в статье об ошибках ИИ.

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

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

«Один проект» на /services означает один продукт, один поток и одну задачу в работе. Следующая ждёт в очереди. Срок всего приложения определяют по этой очереди, как разобрано в статье о сроках разработки.

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

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

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

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

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

2. Считайте прибавку прибыли относительно прежнего канала. Перенос телефонного заказа в приложение сам по себе новой прибыли не создаёт.

3. Разделяйте покрытие текущей подписки и возврат вложений до запуска. Добавляйте эксплуатацию и продвижение, учитывайте новые платежи за разработку.

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

5. Покупайте подписку под очередь проверяемых задач. Решайте о продолжении по завершённым заказам и накопленному результату.