Как сделать приложение Такси, подобное Uber, в 2022 году: процесс, стоимость и советы 🚖

Вступление

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

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

Uber считается типичным прорывным стартапом , оказавшим огромное влияние на индустрию такси во многих городах по всему миру. Это только одна из причин, по которой многие основатели, стремящиеся создать приложения для совместного использования поездок, моделируют свои продукты ориентируясь на Uber. В первом квартале 2020 года пользователи забронировали в приложении 1,65 миллиарда поездок , что помогло компании получить доход в размере 15,8 миллиарда долларов. Стоимость IPO Uber составила 82,4 миллиарда долларов .

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

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

Основы разработки Uber-подобных приложений

Как работает Убер?

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

Например, в Нью-Йорке пользователи могут выбирать из следующего:

• UberX — экономичные поездки, когда пользователь бронирует весь автомобиль
• UberXL — доступные поездки для 5 пользователей
• Черный — ездит на роскошных автомобилях премиум-класса.
• Черный внедорожник — поездки премиум-класса для 5 пользователей с профессиональными водителями
• Автокресло — автомобили с детским автокреслом.
• WAV — поездки в транспортных средствах, оборудованных для гостей на инвалидных колясках.

Кроме того, Uber подключен к другому удобному приложению той же компании, Uber Eats. Пользователи могут легко перемещаться между приложениями. Такой тип интеграции должен учитывать каждый основатель при создании приложения для совместного использования пассажиров после стадии MVP ( минимально жизнеспособный продукт ).

Сколько приложений вам действительно нужно?

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

1. Driver App
   Это приложение для водителей , которые могут разделить свое местоположение, найти оптимальные матчи и получать оплату за свои услуги. Обычно он состоит из таких функций, как запросы в реальном времени и по расписанию, сведения о поездках и инструменты для отслеживания платежей.
2. Приложение для пассажиров
   Это приложение позволяет пользователям легко запрашивать поездки. Он может включать такие функции, как сопоставление пассажиров с водителями в реальном времени, обновления информации о поездках в режиме реального времени, проверенные профили для дополнительной безопасности и удобный платежный портал.
3. Панель администратора для владельца приложения
   Обычно она представляет собой веб-панель администратора, доступную из любого браузера. Панель администратора — ключевой компонент успешного приложения для совместного использования автомобилей. Вы можете настроить его с помощью таких функций, как управление водителями и пассажирами или отчеты и аналитика.

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

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

Основные характеристики:

• Геолокация и маршрутизация
• Звонок или текстовое сообщение водителю прямо из приложения
• Состояния езды
• Оценка стоимости поездки
• Платежи
• Всплывающее уведомление
• Регистрация и управление личными данными
• Личный профиль

Расширенные возможности:

• Бронирование поездок для других
• Планируйте поездки заранее
• Разделение стоимости поездки с попутчиками

Особенности приложения такси для водителей

Основные характеристики:

• Отчетность водителя
• Оптимизация маршрута
• Опция «Активный / Неактивный»
• Ежедневные или ежемесячные отчеты о бронировании и доходах
• Геолокация и маршрутизация
• Звонок или текстовое сообщение пассажиру прямо из приложения
• Состояния езды
• Оценка стоимости поездки
• Всплывающее уведомление
• Регистрация и управление личными данными
• Личный профиль

Расширенные возможности:

• Бесплатная отмена в течение установленного периода времени
• Сложные отчеты и тепловые карты (например, для отображения уличного движения)

Основные функции, выполняемые административной панелью Uber

• Добавление и удаление админов
• Управление привилегиями администраторов
• Просмотр списка драйверов
• Обновление данных драйверов
• Проверка драйвера
• Изменение цены поездки

Модели дохода для Uber приложения

Uber не владеет автопарком, а вместо этого получает прибыль, выступая в качестве посредника между водителями и пассажирами. Компания взимает со своих водителей 25% комиссию по всем тарифам за использование программного обеспечения, сбор и перевод сборов, комиссию по кредитной карте и отправку счетов клиентам. Однако это не означает, что ваше приложение для совместного использования или совместного использования автомобилей должно работать одинаково.

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

• Взимание сборов с пассажиров
• Взимание сборов с водителей
• Реклама в приложении
• Интеграция с другими приложениями и сервисами

7 этапов процесса разработки приложения такси

Вот основные этапы процесса разработки мобильного приложения:

1. Выберите компанию для разработки вашего приложения.
   Исследование, анализ и выбор компании, с которой вы будете сотрудничать с вашим приложением для совместного использования. Подписание договора с независимым подрядчиком. 
2. Обнаружение продукта — определите, что вы хотите создать, для кого и почему.
   Уточнение видения вашего приложения, определение целей вашего продукта и его конечных пользователей. Решите, какие функции наиболее важны для создания вашего MVP, на каких платформах будет работать ваше приложение, и определите свои модели монетизации. 
3. Дизайн приложения UX / UI — определите, как ваше Uber приложение будет работать и выглядеть.
   Создание карты пути пользователя, интерактивных макетов, визуальных пользовательских интерфейсов и дизайна движения (анимация и переходы между экранами). 
4. Запуск и настройка проекта — последние приготовления перед началом разработки приложения.
   Обеспечение того, чтобы владелец продукта знал команду разработчиков, и наоборот. Определение каждой роли в команде, соглашение о правилах и следующих шагах, а также инструменты настройки. Настройка среды проекта с использованием передовых практик из таких областей, как управление проектами и DevOps, помогает ускорить и упростить процесс разработки приложений для совместного использования.
5. Разработка приложений с контролем качества
   Производство приложений с непрерывной интеграцией: планирование, код, сборка, тестирование (и повторение). Обеспечение качества на каждом этапе разработки приложения для совместного использования автомобилей с помощью ручных и автоматизированных тестов. Команды разработчиков обычно следуют структуре Scrum и делят работу на короткие итерации, за каждой из которых следует демонстрация.
6. Подготовка и публикация приложения в Google Play Store и Apple Store
   Релиз включает в себя загрузку активов, требуемых законами и рекламными материалами, бета-тестирование, оптимизацию страницы продукта / присутствия в магазине и все остальное, что необходимо для утверждения вашего приложения, чтобы оно прошло как можно более гладко. Подготовка к запуску важна, если вы хотите, чтобы ваше такси приложение, похожее на Uber, выделялось из толпы и добивалось успеха.
7. Этап после разработки — обслуживание и дальнейшая разработка такси приложения.
   Обнаружение сбоев, мониторинг статистики приложения, улучшение продукта и дальнейшее развитие. Ваше такси приложение остается привлекательным, адаптируется к меняющимся рыночным условиям и отзывам пользователей.

Приложение для пассажиров — оценка стоимости основных функций и мнение разработчиков

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

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

Геолокация и маршрутизация: 150 — 200 часов

Для первого расчета самого быстрого маршрута требуется стабильное интернет-соединение. В дальнейшем пользователь устройства может находиться в автономном режиме, поскольку маршрут сохраняется в памяти телефона. Вы можете получить данные о точном местоположении пользователя только тогда, когда он подключен к Интернету, потому что использование одного только GPS может привести к ошибочным показаниям (до нескольких десятков метров!).

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

Конечно, может случиться так, что водитель или пассажир поменяют свое устройство во время поездки (например, из-за того, что оно сломается). В этом случае поездку необходимо воссоздать на основе данных, хранящихся на сервере. Однако это очень крайний случай.

Звонок или текстовое сообщение водителю прямо из приложения: 50 — 100 часов.

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

Состояния езды: 100 — 120 часов

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

Ориентировочная стоимость поездки: 16-32 часа

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

С технической точки зрения оценка стоимости поездки на начальном этапе важна из-за потенциальных проблем (таких как отсутствие доступа в Интернет или GPS), поскольку стоимость поездки может быть неправильно списана, что приведет к потере водитель или пассажир.

Выплаты: 105 — 175 часов работы разработчиков.

При создании этой функции обязательно обратите внимание на две проблемы: пользовательский интерфейс (UX) и безопасность. Лучше всего использовать собственные решения, такие как Apple Pay или Google Pay, которые предлагают быстрые и безопасные транзакции. Кроме того, вам следует рассмотреть возможность оплаты наличными — оплата через приложение может стать проблематичной в регионах с плохим подключением к Интернету (это зависит от региона, в котором вы планируете выпустить свое приложение).

Push-уведомления: 90–160 часов

Важно, чтобы взаимодействие между сервером и клиентом осуществлялось с помощью push-уведомлений, поскольку они уменьшают сетевой трафик (в первую очередь для сервера), а приложение может быстро уведомлять пользователей о событиях, даже если оно работает в фоновом режиме.

Регистрация и управление личными данными: 90-150 часов

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

Личный кабинет: 40-60 часов

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

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

Приложение для водителей — оценка стоимости основных функций и мнение разработчика

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

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

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

Отчетность водителя: 16-24 часа

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

Оптимизация маршрута: 24-60 часов

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

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

Вариант «Активный / Неактивный»: 30–50 часов

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

Ежедневные или ежемесячные отчеты о бронировании и доходах: 70-110 часов.

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

Звонок или текстовое сообщение водителю прямо из приложения: 50 — 100 часов.

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

Остальное:

Остальные функции аналогичны описанным в разделе «Приложение для пассажиров»:

• Геолокация и маршрутизация: 150 — 200 часов
• Состояния езды: 100 — 120 часов
• Ориентировочная стоимость поездки: 16-32 часа
• Push-уведомления: 90–160 часов
• Регистрация и управление личными данными: 90-150 часов
• Личный кабинет: 40-60 часов

Бэкэнд-разработка приложения для райдшеринга (2,500 — 3200 часов)

Для любого Uber-подобного приложения вам также понадобится серверная часть — централизованное удаленное приложение. Хотя могут существовать мобильные приложения, которые вообще не используют бэкэнд или имеют бэкэнд в упрощенной форме (например, Firebase или Serverless), Uber-подобные приложения, как правило, сложны и требуют создания полноценного, индивидуального бэкенда. приложение .

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

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

Под капотом мобильных приложений, веб-приложений и административных панелей только команды (например, «найди мне драйвер») и запросы (например, «сколько я буду платить?») Для данных, которые разрабатываются, разбиваются на разделы, хранятся, и логически вычисляется на удаленном сайте. Все это требует усилий.

Типичные обязанности бэкэнда в Uber-подобных приложениях включают:

• Аутентификация и авторизация пользователей
• Согласованность данных — статус поездки, доступность водителей
• Алгоритмы (например, выбор водителей для поездки или расчет стоимости поездки)
• Хранение данных и файловое хранилище
• Управление платежами, подписками, премиум-статусом и т. Д.

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

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

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

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

Разработка админ-панели приложения для райдшеринга (350 — 500 часов)

Панель администратора — это место, где вы или сотрудники вашего бэк-офиса («администраторы» приложения) можете видеть множество различных типов информации о приложении и / или изменять некоторые его настройки. Как правило, нет ограничений на то, какие данные там можно увидеть. Однако чем больше данных отображается, тем выше стоимость админ-панели. Точно так же каждое значение, используемое в приложении, может оказаться значением, настроенным через панель администратора, но это также делает панель более дорогостоящей.

Трудно найти правильный баланс между тем, сколько показывать и сколько делать настраиваемым. С одной стороны, вы хотите дать администраторам как можно больше полномочий. Но, с другой стороны, у всего есть своя цена. Раздутая админ-панель может сделать весь проект более затратным и сложным, не говоря уже о том, что это также может отложить запуск приложения. Обычно на этапе MVP админ-панели являются основными для раннего запуска. По мере развития проекта у нас появляется все больше информации от пользователей (и администраторов!) О том, какие данные имеют решающее значение. Помните, что функции могут быть добавлены в панель администратора позже.

В нашем случае этап MVP админки содержал:

• Добавление и удаление админов
• Управление привилегиями администраторов
• Просмотр списка драйверов
• Обновление данных драйверов
• Проверка драйвера
• Изменение цены поездки

Какие еще факторы влияют на стоимость разработки приложения для такси?

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

Вот краткая разбивка факторов, которые необходимо учитывать при оценке.

• Количество и сложность функций
  Будет ли ваше приложение для пассажира / водителя включать только базовые функции или также расширенные? Как набор функций, так и их технические требования будут иметь прямое влияние на количество часов, которое потребуется разработчикам для создания вашего приложения, и, следовательно, на его окончательную стоимость.
• Платформа.
  Если вы хотите, чтобы ваше приложение получило максимально широкий охват, разработайте его как для iOS, так и для Android. Но, если ваш бюджет ограничен, вы можете начать с MVP, созданного для одной из платформ — выберите ту, которую ваша целевая аудитория использует больше всего.
• Настройка команды
  Если вы создаете сложное приложение и хотите как можно скорее выпустить его на рынок, стоит нанять более крупную команду, чем стандартная (4 разработчика на платформу). Более того, если вы заботитесь о качестве продукта и эффективности процесса разработки программного обеспечения, включите в свою команду Скрам-мастера и специалиста по обеспечению качества.
• Почасовая ставка разработчиков.
  Если вы нанимаете команду разработчиков, это сильно повлияет на стоимость вашего проекта. Вот разбивка средней почасовой ставки членов команды разработчиков в разных регионах мира (Источник: Отчет Accelerance за 2020 год ):
  

Окончательная стоимость разработки такого приложения, как Uber

Итак, сколько стоит разработка приложения для совместного использования поездок в стиле Uber?

Сделаем следующие предположения:

• Мы собираемся создать Uber-подобное приложение для 2-х платформ (iOS и Android),
• Настройка команды: 3 мобильных разработчика на платформу , 4 Backend разработчика , 1 Frontend Developer, 1 UX / UI Designer, 1 Scrum Master и Расширенный план QA + надстройка Backend Tests ( подробнее о наших планах QA и надстройках ) ,
• Приложения для iOS и Android + панель администратора создаются одновременно, а бэкэнд-разработка начинается примерно через две недели.
• Дизайнер UX / UI начинает свою работу за 2 недели до начала фазы разработки.
• При разработке приложения для iOS используются те же почасовые оценки, что и для приложения для Android (на практике эти значения могут незначительно отличаться друг от друга).

Сколько работает команда?

• Один месяц состоит из 4-х недельных спринтов.
• Каждый разработчик работает по 35 часов в неделю.
• Дизайнер работает по 35 часов в неделю.
• Ежемесячная сумма оплачиваемых часов Скрам Мастера составляет 15% от часов, зарегистрированных разработчиками и дизайнерами в течение месяца.
• QA Engineer работает 20 часов в неделю (расширенный план QA). Надстройка Backend Tests дает вам дополнительные 25 часов тестирования в месяц (тестирование API, регрессионное тестирование Backend).

Какая почасовая оплата у каждого члена команды?

• Почасовая ставка разработчика iOS и Android = 60 долларов в час *,
• Почасовая ставка UX / UI Designer = 60 долларов в час,
• Почасовая ставка Scrum Master = 55 долларов в час,
• Почасовая ставка QA Engineer = 55 долларов в час.

* Обратите внимание, что почасовые ставки могут различаться в зависимости от платформы и страны. 60 долларов — это типичная почасовая ставка в Восточной Европе. 

Общая стоимость разработки такси приложений (включая все, от UX / UI-дизайна до контроля качества).

Приведенные ниже расходы основаны на:

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

	Часы (нижний регистр)	Часы (высокий корпус)
Пассажирское приложение (iOS + Android)	1,314	2,074
Приложение для водителя (iOS + Android)	1,352	2132
Панель администратора	350	500
Бэкэнд	2,500	3 200
UX / UI Дизайн (все приложения)	540	600
Гарантия качества (все приложения + серверная часть)	525	735
Скрам Мастер	908	1,276

	Стоимость (низкий случай)	Стоимость (высокий случай)
Пассажирское приложение (iOS + Android)	78 840 долл. США	$ 124 440
Приложение для водителя (iOS + Android)	81 120 долл. США	127 920 долл. США
Панель администратора	21 000 долл. США	30 000 долл. США
Бэкэнд	150 000 долл. США	192 000 долл. США
UX / UI Дизайн (все приложения)	32 400 долл. США	36 000 долл. США
Гарантия качества (все приложения + серверная часть)	28 875 долл. США	40 425 долларов США
Скрам Мастер	49 962 долл. США	70 175 долл. США
СУММ	442 197 долл. США	620 960 долл. США

Подводя итог: весь процесс разработки приложения, такого как Uber, обойдется вам в ~ 442 000–621 000 долларов  (версия MVP).

Все самое важное уже включено в эту цену. UX / UI-дизайн, приложение Passenger для iOS и Android, приложение Driver для iOS и Android, панель администратора, внутренняя разработка, обеспечение качества, обеспечивающее безопасность всех приложений и серверной части, а также работа мастера Scrum, который сделает процесс разработки плавным и эффективным. .

Время, необходимое для разработки приложения такси (Uber)

Весь процесс проектирования и разработки приложения для райдшеринга займет ~ 5-7 месяцев (версия MVP).

Обратите внимание, что приведенные выше данные являются ориентировочными.

Лучший технологический стек для приложения такси, такого как Uber

Ключевым выбором при создании Uber-подобного приложения является SDK для карт и навигации. На первый взгляд, Google Maps — очевидный выбор. Однако в некоторых странах Карты Google могут вызывать проблемы с законом или отсутствовать точные карты. В нашем недавнем проекте мы использовали Mapbox, потому что это инструмент с открытым исходным кодом с отличной документацией и SDK, который использует Open Street Maps.

Второе по важности — это правильный выбор архитектуры . Мы должны помнить, что основная функция приложения — карта — должна быть видна на большинстве экранов. На наш взгляд, такое приложение должно быть основано на архитектуре Single-Activity Architecture . Вы можете использовать ViewModels с компонентом навигации , например, или создать собственное решение, в котором все основано на представлениях (в нашем Uber-подобном проекте мы выбрали второй вариант). Это означает, что некоторые виды закрываются на большом экране (экране). Экран можно понять как фрагмент.

Мы также должны учитывать внедрение зависимостей . Для нашего проекта мы выбрали Dagger 2 от Google, потому что это наиболее масштабируемое решение и лучшее с точки зрения скорости. Поскольку наша архитектура была проприетарным решением, мы также использовали Assisted Injection by Square .

Кроме того, важно выбирать инструменты, которые являются родными для iOS и Android, из-за оптимизации размера приложения и его скорости. Выбор общих технологий тоже важен. Например, вы можете выбрать Firebase Push Notification для push-уведомлений, чтобы серверная часть могла интегрироваться только с одной общей службой, что значительно сокращает время внедрения.

Пример технического стека для приложения такси GPS-навигации и приложения, подобного Uber:

	приложение для iOS	Приложение для Android
Язык	Swift 5.1	Котлин
Аналитика	Firebase	Firebase
Всплывающее уведомление	Firebase	Firebase
Отчеты о сбоях	Firebase Crashlytics	Firebase Crashlytics
Сети	Моя	OkHttp + Модернизация
Карты	MapBox	MapBox
Набор инструментов базы данных	GRDB	Номер
Локальный картографический сервер	GCDWebServer	Мок веб-сервера
Непрерывная интеграция	Bitrise	Bitrise
Архитектура	MVP + координаторы	Поток MVI + инфляция-закачка
Единичные тесты	Быстрый, Шустрый, Тестирование снимков, Источник	KoTest, JUnit, AndroidXTest
Безопасность	Брелок, CocoapodsKeys	Зашифрованные общие настройки
LayoutSDK	SnapKit	Собственный, ConstraintLayout
Инструментарий пользовательского интерфейса	Родной	Материал

Бэкэнд

Время выполнения	Node.js
Язык	Машинопись
Фреймворк веб-приложений	выражать
Тесты	Мокко, Чай, Супертест
Развертывание приложения	AWS Elastic Beanstalk
База данных (адресация данных)	MySQL
База данных (данные пользователя)	DynamoDB
IaC (Инфраструктура как код)	Terraform
Непрерывная интеграция	Семафор CI
Документация, Приемочные испытания	Почтальон