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

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

Что на самом деле придётся написать

Вот неполный список правил, которые есть в любой доставке воды 19 л и которых нет ни в одном макете каталога.

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

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

Почему мы начинаем не с нуля

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

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

Как устроена техника

Приложения клиента и курьера написаны как веб-приложения на React и работают в браузере. Те же экраны упакованы в нативные проекты iOS и Android через Capacitor, причём сборка лежит внутри приложения. Для бизнеса это значит одно: экраны делаются один раз, а не три. На iOS и Android работают нативные пуши и виброотклик, сборка идёт в облаке через Codemagic.

Про разницу подробнее написано на странице о PWA и о публикации в сторах.

Что остаётся за вами

Кое-что нельзя сделать за компанию. Аккаунт разработчика Apple оформляется на ваше юрлицо, и то же с Google. Договор на SMS вы заключаете с оператором сами, потому что отправителем будете вы. Тексты согласий и политики конфиденциальности должен проверить ваш юрист.

Что спросить у любого подрядчика

Неважно, с кем вы в итоге будете работать, эти вопросы стоит задать до договора.

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

Если вместо ответа вы слышите «это проработаем на этапе аналитики», значит, сроки и смета пока считаются без этих задач.

Когда лучше писать своё

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