Приложение такси «Везучая Трёшка»: как выплаты водителям сократились с двух суток до минут

Что было до переделки

Новые приложения появились потому, что старые не справлялись. С чего начинали:

- ошибки в платежах и лишние долги у клиентов; - выплаты водителям по двое суток; - платная карта 2GIS, которая тормозила при поиске адреса.

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

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

Два приложения на одном ядре

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

Оба собраны на Flutter, потому что такси требует GPS в фоне и работы при плохой сети. Общая часть кода держится в одном месте, поэтому правки переносятся между двумя приложениями. Оба опубликованы в RuStore.

Для бизнеса это значит одно: два приложения с общим ядром в поддержке проще, чем два разных проекта.

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

Выплаты за минуты

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

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

Деньги в приложении требуют внимания к персональным данным и банковским правилам. Формулировки и порядок хранения согласуйте с юристом и банком.

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

Своя карта вместо 2GIS

Адреса и маршруты держатся на собственной геоплатформе. Данные OpenStreetMap загружаются в PostgreSQL с PostGIS, поиск и геокодинг работают на FastAPI. Автокомплит и геокодинг отвечают быстрее 100 миллисекунд, поэтому подсказки адресов появляются почти сразу, пока человек печатает.

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

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

Чему научиться другим

Если у вас есть водители, исполнители или партнёры, которым нужны выплаты, из кейса можно взять четыре вещи:

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

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

Ещё один урок касается аккаунтов. Аккаунты в RuStore, App Store и Google Play оформляют на компанию, иначе приложение потом сложно передать. Этот пункт есть в чек-листе технического задания.

Если аккаунты уже оформлены на подрядчика, переоформить их можно, но это отдельная работа с магазинами. Лучше сделать правильно с первого дня. Такая проверка добавляет несколько дней к плану, но избавляет от переписки с магазинами после запуска. Что делать дальше, разобрано в статье «Своё приложение для бизнеса в 2026 году».

Когда хватит самому, когда звать студию

Если у вас один сервис и один тип пользователей, начинать можно с одного приложения и простой оплаты. Пакет с одним приложением, сервером, авторизацией, профилем и публикацией в один магазин стоит от 500 000 ₽ и занимает 4–6 недель.

Два приложения с платежами, push, аналитикой, интеграциями и публикацией во все магазины входят в пакет от 1 200 000 ₽, срок 6–10 недель. В пакет входит 90 дней поддержки. Точный состав и цену фиксируем в договоре. Подробнее на странице мобильного приложения.

Цены по рынку и чек-лист собраны в бесплатном гайде «Мобильное приложение для бизнеса» в нашем боте.