Case study · Mobility · Ridesharing

Convenient Taxi Aggregator — three-app mobility platform

Published Aug 23, 2023 · Updated Aug 23, 2023 · By YuSMP Group Engineering

How we shipped a production ride-hailing aggregator — native rider and driver apps plus a real-time dispatcher console — built on Laravel and PostGIS with WebSockets streaming GPS at one-second cadence, document verification on driver onboarding, and audit-ready ride records ready for US and EU mobility regulators.

IndustryMobility · Ridesharing

Project year2023

EngagementFixed price + support

Convenient Taxi Aggregator — rider booking, real-time vehicle tracking, US and EU mobility platform

The brief — a phone-dispatched taxi business that needed to scale nationwide

A regional taxi operator running on phone calls and paper dispatch wanted to expand from a single city to full national coverage and become a credible aggregator for US and EU mobility markets. The legacy operation capped growth at the volume a human dispatcher could handle, made it difficult to onboard new drivers without paper handovers, and exposed the business to inconsistent ride records that would not survive a regulator audit in California or Germany. The team needed a real-time digital platform — rider booking with a price preview, driver onboarding with document verification, a dispatcher console that could supervise hundreds of vehicles across multiple cities, and an end-to-end ride lifecycle that could be reconstructed line-by-line from data. We built the aggregator as three coordinated products on a shared Laravel + PostGIS backend with WebSockets streaming live position updates: a native Swift rider app, a native Kotlin driver app, and a React dispatcher console. The result is a mobility platform that handles a national fleet, ships audit-ready ride records for US and EU jurisdictions, and is positioned for compliant launch under the privacy expectations of the United States and the European Union from day one.

Project highlights

Native Swift rider app Native Kotlin driver app React dispatcher console Laravel + PostGIS backend WebSockets GPS streaming Driver document verification Cash & card payment flows Nationwide coverage ready · US & EU

By the numbers

A snapshot of what the Convenient Taxi Aggregator build delivered across rider, driver, and dispatcher surfaces on a shared real-time backend.

3coordinated apps — native rider iOS, native driver Android, React web dispatcher console

1sGPS publish cadence per active driver, fanned out to dispatchers and riders over WebSockets

2payment rails — cash settlement and card processing, reconciled per shift end

100%of rides written to an immutable audit log, retrievable per regulator request

2app stores live — Apple App Store and Google Play across US and EU storefronts

14–20 wktypical delivery window for a comparable three-app mobility MVP at single-city scope

Taxi aggregator rider app — post-trip receipt with driver name, trip ID, total fare and star rating prompt

Why native mobile over a SaaS ride-hailing stack or Flutter

The platform decision dominates every other architectural choice in a mobility build. We chose native Kotlin and Swift over a SaaS ride-hailing stack and over a Flutter MVP because the trade-offs line up cleanly with a real production aggregator. SaaS stacks lock the operator into the vendor's pricing engine, their fee schedule, and their data residency choices — the last of which is fatal in the United States and the European Union, where ride records are subject to regional privacy and mobility regulations. Flutter is excellent for forms-heavy apps but pays a measurable tax on continuous one-second GPS streaming and on App Store and Google Play review for background-location permission justification; native Kotlin foreground services and Swift CoreLocation give us direct, well-documented control over the carrier-handoff scenarios mobility users hit every day.

The build leans on Apple CoreLocation on the rider and driver iOS clients, the Android location APIs on the driver Kotlin client, and PostGIS as the spatial index on the backend — a citable, open-source spatial extension that gives us tile-based dispatcher fan-out without locking the operator into a vendor map cloud.

Native mobile vs SaaS ride-hailing stack vs Flutter — at a glance
Dimension	Native mobile (Taxi Aggregator)	SaaS ride-hailing stack	Flutter MVP
GPS streaming latency	~1 second publish cadence via foreground service / CoreLocation	Vendor-imposed, often 5–10s	Platform-channel hop adds ~150–300 ms jitter
Document-verification fit	Full control of KYC pipeline + retention policy	Vendor pipeline; opaque retention	Bridge to native camera + OCR adds friction
Dispatcher WebSockets fit	Custom PostGIS tile fan-out, full schema control	Vendor-defined topics; can't shape payload	Web dispatcher is separate React app; mobile parity strong
Regional pricing flexibility	Operator-owned pricing engine — surge, time, distance, region	Vendor pricing primitives only	Same engine reachable; UI tweaks ship faster
Audit-ready ride records	Operator-owned event store, immutable	Vendor-hosted; export-only access	Same backend; identical guarantees
Battery behavior on shift	Foreground service / background mode tuned per OEM	Vendor wrapper; OEM-killed on Samsung / Xiaomi	OEM tuning still required via native bridge
Data residency control	Operator-owned infra in US or EU regions	Vendor region map only	Same backend control; identical posture

References: PostGIS documentation, Apple CoreLocation reference, Android location services reference.

Taxi aggregator driver app — live map with full A-to-B route drawn and nearby vehicle positions

Driver app — Kotlin, foreground service, and the shift lifecycle

The driver client is written in Kotlin with Jetpack Compose for the UI and a foreground service built on the Android location APIs. The foreground service is mandatory: on Samsung, Xiaomi, OnePlus, and Pixel device families, aggressive battery optimizers terminate background-only location-streaming processes within minutes, breaking the dispatch contract a driver implicitly signs up for at the start of a shift. The service displays a minimal persistent notification, requests the foreground-location permission with a clear-purpose disclosure that the Google Play reviewer expects, and publishes GPS position over a persistent WebSocket connection at a one-second cadence. WorkManager handles non-urgent operations — earnings sync, document re-upload, shift summaries — with backoff semantics that respect Doze mode and battery saver across Android 10 through Android 14.

The shift lifecycle is the spine of the driver experience. A driver opens the app, completes a quick vehicle check, taps Go online, and the app moves through a clear state machine — online, en-route, on-trip, completing, offline. Each state writes to the immutable ride-event log on the backend, which is what later powers audit-ready reporting for US and EU regulators. Cash and card payments both close the trip through the same flow: a tap to accept cash, or a card-processed receipt the rider sees in their app instantly. The same engineering team carries iOS and Android in lockstep as part of our mobile app development practice.

Taxi aggregator dispatcher view — live city map with vehicle fleet positions and pickup address

Dispatcher console — React, WebSockets, and PostGIS tile fan-out

The dispatcher console is a React single-page application that has to render hundreds of moving vehicles, dozens of active ride requests, and a live driver-status board without making the operator's CPU fan audible. It rides on a WebSockets fan-out layer with PostGIS as the spatial index: drivers publish position updates over a persistent connection; the backend buckets positions into spatial tiles and pushes deltas only to the dispatchers viewing each tile. The console keeps a client-side R-tree so rendering thousands of markers on the Leaflet-backed map stays smooth, and animation interpolation between updates makes the visual experience read as continuous motion.

The dispatcher is also the single pane of glass for human intervention. Document-verification status, shift state, ride disputes, and earnings counters share the same channel as positions, so a dispatcher who sees a stuck driver or a stranded rider can reroute, refund, or contact in seconds. The console pairs with our cloud & DevOps practice for the WebSockets infrastructure, which is sized to absorb the load profile of a national fleet — bursty rush-hour traffic, multi-region failover, and the kind of incident-response window where every second of stale data costs money. Multi-city dispatchers can scope their view by region without rebuilding the page, which is how a single console covers the Netherlands and the US East Coast at the same time during cross-Atlantic on-call rotations.

Taxi aggregator pricing — Econom 10 lei, Comfort 14 lei, SUV 18 lei fare tiers with ETA and LET'S GO CTA

Pricing engine, KYC pipeline, and audit-ready posture

The pricing engine and the document-verification pipeline carry the regulatory weight of the platform. The pricing engine is a small domain-specific layer on the Laravel backend that takes base fare, distance, time, region, and dynamic factors and returns a transparent rider preview before the rider taps Book. The transparency is deliberate: regulators in California, Texas, and the United Kingdom increasingly require ride-hailing operators to disclose pricing logic, and an opaque surge multiplier is a regulatory liability we did not want to bake in. Operators can adjust regional pricing — different base fares for the Netherlands versus Germany versus Florida — from a single configuration store without code releases.

Driver onboarding flows ingest licence, vehicle registration, insurance, and a background check, then run them through a verification queue that combines automated checks (document liveness, expiry parsing, OCR confidence) with a human review stage. Records are retained per local mobility regulations and encrypted at rest with key rotation; the system keeps an immutable audit trail per driver and per ride. The posture is built to align with GDPR obligations for users in the European Union and CCPA / CPRA obligations for users in California and the broader United States.

Compliance posture: GDPR-aligned · ISO 27001 ready · SOC 2 Type II in progress · HIPAA-capable · CCPA-acknowledged.

Delivery methodology

A five-phase build that took the aggregator from operator requirements to production across rider, driver, and dispatcher surfaces.

Phase 1

Discovery & requirements

Operator workflow mapping (phone dispatch baseline), nationwide expansion model, regional pricing primitives, US and EU mobility-regulation review for ride records and driver onboarding.

Phase 2

Architecture & data model

Laravel + PostGIS backend skeleton, WebSockets fan-out design, ride-event store with immutable append-only schema, KYC pipeline outline, payment-rail abstraction (cash + card).

Phase 3

Platform builds — supply first

Native Kotlin driver app and React dispatcher console shipped first to seed supply; native Swift rider app shipped second; one-tap booking, price preview, real-time tracking.

Phase 4

Audit-ready hardening

Driver KYC end-to-end, ride-record retention policy per jurisdiction, dispatcher access control, PostGIS load test at projected national fleet size, store-review choreography.

Phase 5

Launch & telemetry

App Store + Google Play submission across US and EU storefronts, dispatcher rollout per city, on-call runbooks for the WebSockets layer, post-launch shift-end reconciliation.

Multi-city scaling, on-call rotation, and the dispatcher handoff

A national taxi aggregator is, operationally, a many-cities problem dressed up as one product. Each city has its own driver pool, its own peak-hour pattern, and — in the US and EU — its own regulatory profile. The platform models a city as a first-class tenant of the dispatcher console: dispatchers see only their assigned cities, regional pricing rules live in a per-city configuration store, and the PostGIS tile fan-out scopes WebSocket traffic by city so the rush hour in one city never starves another's dispatcher of updates. On-call rotation works the same way at the engineering layer — the backend, the WebSockets layer, and the dispatcher console are all instrumented through Prometheus and Grafana so an on-call engineer in CET hours can hand off to an on-call engineer covering East-Coast US hours without a verbal sync. The whole subsystem was built to extend cleanly: adding a city is a configuration change against the tenant store, not a code release, and a new market — say, expanding into the United Kingdom or Ireland — drops in without rewriting the dispatch logic.

Launching across the United States and the European Union

The Convenient Taxi Aggregator was architected for mobility operators serving riders and drivers across the United States and the European Union. The English-language build serves users in California, New York, Texas, Florida, and Washington in the US, and users in the Netherlands, Germany, France, Ireland, and Sweden in the EU, without a separate codebase per region. Consent flows are region-aware at the client layer: users in the EU and EEA receive a GDPR-style granular consent screen with separate toggles for ride-record retention and optional product analytics; users in California receive a CCPA-style "Do Not Sell or Share My Personal Information" disclosure in the same flow. Data-handling practices are aligned with GDPR for European users and with the US state-privacy patchwork — CCPA / CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas), and Oregon CPA. Driver onboarding pipelines retain documents per local mobility-regulation requirements, and audit-ready ride records make regional compliance an honest-disclosure exercise rather than a per-jurisdiction data segregation problem.

Backend deployment runs across EU and US regions in parallel — Netherlands, Germany, France, Sweden, and Ireland for EU coverage; US East and US West for North America — with PostGIS instances and WebSockets gateways provisioned identically through Terraform. The matching service that picks the nearest available driver runs stateless workers pinned to either US or EU regions for future data-residency commitments. Both the App Store age rating and the Google Play content rating were calibrated for a mobility platform, and the in-app privacy policy was drafted to document exactly the architecture above, citing GDPR obligations and California CCPA obligations directly. The engineering team behind the build runs a CET workday with East-Coast US overlap (9 AM–1 PM ET) for stand-ups, store-review choreography, and dispatcher incident response — the timezone that lets a US operations team and an EU engineering team share four hours of live overlap every day.

Tech stack and roadmap

Swift SwiftUI CoreLocation Kotlin Jetpack Compose Foreground Service React Leaflet PHP Laravel PostgreSQL PostGIS Redis WebSockets Google Maps SDK Stripe Docker Terraform Prometheus Grafana

The active custom software development roadmap for the aggregator includes a corporate-rides tier for B2B accounts in the US and EU, deeper integration with regional payment processors, an offline-tolerant driver app for low-coverage US rural routes, and a rider scheduling layer for pre-booked rides. Infrastructure plans include further PostGIS sharding for projected multi-million-ride throughput, an internal continuous-verification harness for the ride-event store, and a future independent readiness assessment scaffolded into the cloud & DevOps roadmap.

Build a mobility platform like this — talk to us

If you are planning a ride-hailing aggregator, a corporate-mobility platform, or any real-time multi-app product where the dispatch story has to hold up under a regulator review for audiences in the US and EU, we have shipped this stack end-to-end and can compress the build timeline meaningfully. The engineering team behind it sits inside YuSMP Group. We work fixed-price for well-scoped MVPs and on dedicated development teams for ongoing delivery, with a CET workday and a guaranteed East-Coast US overlap (9 AM–1 PM ET) window for stand-ups, demos, and incident response.

Book a discovery call See mobile development services

Frequently asked questions

How much does it cost to build a three-app taxi aggregator like Uber or Bolt?

A focused MVP covering a native rider app, a native driver app, and a web dispatcher console with real-time GPS streaming, basic pricing, and cash plus card payments typically costs $180k–$360k. Adding nationwide coverage, document verification with KYC pipelines, surge-style dynamic pricing, audit-ready ride records, multi-city dispatcher views, and SLA-grade WebSockets infrastructure brings a production-grade platform to $400k–$850k. The dominant cost drivers are the dispatcher real-time layer, driver onboarding, and the GPS-streaming backend tuned for US and EU latency.

Why native iOS and Android over Flutter for a ride-hailing rider and driver app?

Ride-hailing apps stream GPS at one-second cadence, run the screen on while driving, and depend on platform-specific battery and background-location APIs that mature faster on native than on Flutter wrappers. Native Kotlin and Swift expose the foreground-service and CoreLocation primitives directly, so the driver app stays alive on Samsung, Xiaomi, OnePlus, Pixel, and iPhone for an entire shift without battery-optimizer kills. Flutter is excellent for forms-heavy apps but pays a measurable tax on continuous-location streaming and on App Store review for background-location permission justification.

How do you design a dispatcher console that updates in real time across hundreds of vehicles?

A real-time dispatcher console rides on a WebSockets fan-out layer with a server-side spatial index. Drivers publish position updates over a persistent connection; the backend uses PostGIS to bucket positions into tiles and pushes deltas to dispatchers viewing each tile. The console keeps a client-side R-tree so rendering hundreds of moving markers stays smooth in a browser. Document-verification status, shift state, and earnings counters share the same channel so dispatchers see one consistent state and intervene in seconds, not minutes.

How is a driver document-verification pipeline structured for US and EU mobility platforms?

Driver onboarding flows ingest licence, vehicle registration, insurance, and a background check, then run them through a verification queue that combines automated checks (document liveness, expiry parsing, OCR confidence) with a human review stage. Records are retained according to local mobility regulations — different in California versus Germany versus the United Kingdom — and are encrypted at rest with key rotation. The system keeps an immutable audit trail per driver so the operator can answer regulator questions across US and EU jurisdictions without manual archaeology.

How long does it take to ship a taxi aggregator with rider, driver, and dispatcher apps?

A phased rollout that seeds supply first — driver app and dispatcher console — and then opens the rider app typically takes 14–20 weeks for a single-city MVP. Expanding to nationwide coverage, document verification, surge-style dynamic pricing, and audit-ready ride records adds 8–14 weeks. The real-time WebSockets layer plus PostGIS spatial backend frequently dominate the schedule because they have to hold up under thousands of concurrent driver positions across US and EU regions before launch.

Related cases

More mobility & multi-app platform builds

Automotive · E-commerce

Share this case

LinkedIn X

Plan a similar build

Book a discovery call

← Previous case ZipIt Next case → CheckList