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

Заказ на «приложение как Яндекс Go, только для нашего города» — один из самых частых в мобильной разработке и одновременно один из самых недооценённых. Заказчик видит два экрана: пассажир ставит точку на карте, водитель принимает заказ. За этими экранами — распределение заказов в реальном времени, расчёт цены с учётом пробок, учёт смен и взаиморасчётов с водителями, диспетчерская для звонков, контроль качества и работа с жалобами. И всё это должно работать в час пик, когда сотни устройств одновременно шлют координаты каждые несколько секунд.

Разберём, из чего состоит такси-сервис, когда выгоднее подключить готовую платформу, когда — писать своё, и сколько это стоит. Отдельно — о требованиях, которые в 2026 году предъявляются к перевозчикам и службам заказа легкового такси: их нельзя игнорировать при проектировании.

Кто будет пользоваться системой

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

Сердце системы: распределение заказов

Алгоритм назначения — главное конкурентное преимущество такси-сервиса и самое сложное место. Простейший вариант — предложить заказ ближайшему свободному водителю, подождать 10–15 секунд, затем следующему. Работает на небольшом парке, но на сотне машин начинаются проблемы: «ближайший» по прямой может стоять за рекой, водители отклоняют невыгодные заказы, в час пик очередь заказов растёт быстрее, чем водители успевают отвечать. Зрелые системы учитывают время подъезда по дорожному графу, рейтинг водителя, направление его движения, цепочки заказов, приоритет корпоративных клиентов.

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

Цена поездки и тарифы

• Тариф: подача, минута, километр, минимальная стоимость, ожидание, загородный километр.
• Предварительный расчёт по маршруту с учётом пробок через картографический сервис.
• Повышающий коэффициент при высоком спросе — настраиваемый и с понятным объяснением для пассажира.
• Фиксированная цена против таксометра: при фиксе риск отклонения маршрута берёт на себя сервис.
• Промокоды, корпоративные тарифы, оплата по договору для юрлиц.

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

Требования закона, которые влияют на архитектуру

С 1 сентября 2023 года действует федеральный закон о такси (580-ФЗ), который ввёл региональные реестры перевозчиков, автомобилей такси и служб заказа. Служба заказа легкового такси обязана передавать заказы только перевозчикам и водителям, сведения о которых внесены в региональные реестры, и проверять это. Следовательно, в системе должна быть проверка допуска водителя и машины к работе, хранение данных о путевых листах и предрейсовых осмотрах — или интеграция с сервисами, которые это делают. Конкретный набор обязанностей зависит от вашей роли (перевозчик, служба заказа, самозанятый водитель), поэтому юридическую часть стоит проверить со специалистом до старта разработки.

Приложение водителя важнее, чем кажется

Заказчики тратят основные силы на приложение пассажира — его видят клиенты и инвесторы. Но такси-сервис живёт водителями: если им неудобно, они уходят к агрегатору, и самое красивое пассажирское приложение показывает пустую карту. Водитель работает по 10–12 часов, одной рукой, в машине, с плохой связью и при ярком солнце. Отсюда требования, которые редко попадают в первое ТЗ.

• Крупные кнопки и минимум действий: принять заказ, на месте, начать поездку, завершить — по одному касанию.
• Прозрачный баланс: сколько заработано за смену, какая комиссия удержана, когда выплата. Непонятные списания — главная причина ухода водителей.
• Работа в фоне и при слабом сигнале: координаты буферизуются и отправляются, когда связь вернулась, таксометр не обнуляется.
• Экономия батареи: частота отправки координат меняется в зависимости от статуса — на заказе чаще, в ожидании реже.
• Встроенная связь с пассажиром через подменный номер, чтобы ни одна сторона не видела личный телефон другой.
• Документы и допуск: напоминания об окончании ОСАГО, медосмотре, сроке действия разрешения.

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

Готовая платформа или своя разработка

На российском рынке есть готовые платформы для таксопарков и служб заказа: брендированные приложения пассажира и водителя, диспетчерская, тарифы — по подписке или с комиссией за заказ. Для парка, который хочет своё приложение в городе на 100–500 тысяч жителей, это почти всегда разумный старт. Своя разработка оправдана в трёх случаях.

1. Вы строите не такси, а смежный сервис: перевозка детей с проверенными водителями, трансферы в аэропорт по предзаказу, медицинская перевозка, грузовое такси с грузчиками. Готовые платформы такие сценарии поддерживают плохо.
2. Бизнес-модель отличается от комиссионной: подписка водителей, корпоративный сервис для сотрудников, интеграция с собственной логистикой.
3. Масштаб, при котором комиссия платформы становится больше стоимости собственной разработки и поддержки.

Смета собственной разработки

Ориентировочный состав MVP такси-сервиса на один город. Ставка условно 2 500–3 500 ₽ в час.

Пример расчёта: комиссия против своей платформы

Условный парк: 120 водителей, 1 500 заказов в день, средний чек 450 ₽. Оборот — 675 тыс. ₽ в день, около 20 млн ₽ в месяц. Допустим, готовая платформа берёт 3% с заказа: 600 тыс. ₽ в месяц, 7,2 млн ₽ в год. Своя разработка за 12 млн ₽ и поддержка 2,4 млн ₽ в год (20%) плюс 0,6 млн ₽ на инфраструктуру — 3 млн ₽ в год. Экономия против комиссии — 4,2 млн ₽ в год, окупаемость около 2 лет 10 месяцев. При 500 заказах в день комиссия составит 2,4 млн ₽ в год — меньше, чем одна только поддержка своей системы, и разработка не окупится никогда.

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

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

Технические решения, которые сложно изменить потом

• Карты и геокодинг: российский картографический сервис с понятным тарифом за запрос. Смена провайдера карт через год — дорогая переделка.
• Реальное время: WebSocket-соединения и брокер сообщений для координат и статусов, а не опрос сервера раз в секунду.
• Офлайн-режим водителя: потеря связи не должна сбрасывать поездку и таксометр.
• Мониторинг и алерты: падение распределения в час пик — прямые потери. См. мониторинг сайта и CRM.
• Безопасность: защита от подмены GPS, накруток бонусов и угона аккаунтов. Базовый минимум — в статье двухфакторная аутентификация.

С чего начать

Шаблон сметы в Excel для сравнения предложений подрядчиков по одинаковым строкам можно скачать бесплатно.

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

Начните не с дизайна, а с экономики: сколько заказов в день вы рассчитываете получить через полгода, какая доля из них будет через приложение, а не по телефону, и сколько вы сейчас платите посредникам. Затем — пилот на готовой платформе, если модель типовая, или MVP с минимальным алгоритмом распределения, если нет. Принципы сокращения первой версии описаны в статье MVP за 8–10 недель. Если хотите обсудить архитектуру или получить оценку по своему списку функций — напишите нам, а подробности о нашем подходе к мобильным проектам — в разделе мобильная разработка.