Premium Rides — Ride‑Hailing Platform

Overview

Ride‑hailing platform with rider and driver apps: trip requests, extra fees and taxes, chat with attachments, complaints and violations, payment gateways, and customizable landing pages.

01The challenge

A ride app is not "book a car": price varies by zone, time and vehicle type, drivers may bid instead of accepting a fixed fare, commission differs by plan, incentives are computed in tiers, and a fleet may hold dozens of vehicles behind one wallet.

It is also sold into different markets, each with a different payment gateway and SMS provider — folding all of them into the core would have made every update a risk to everyone.

And safety is not an add-on: an SOS must work, be tracked, and be closed with a documented state.

02What we built

Pricing was built as independent layers that compose: vehicle type, then zone, then surge, then extra charges and ride preferences — so a new pricing policy is configuration, not code. Bidding was built as a parallel path to fixed fares, so a market that prefers it enables it without changing the other.

Every payment gateway and SMS provider became its own module (21 of them) with its own routes and settings, switched on from the panel — a new market means enabling a module, not touching the core.

The financial side runs on separate wallets: rider, driver and fleet-manager wallets, each with its own history and withdrawal requests. Commission, incentives and subscriptions all write into that ledger.

The SOS is an entity with its own statuses, activity log and zones — not a notification that gets sent and forgotten.

03The outcome

The platform can launch in a new market by enabling the right payment and SMS modules and drawing and pricing its zones — with no new branch of the code.

Driver and fleet finances close: every commission, incentive, subscription and payout has a row in the wallet ledger, so reconciliation is a query rather than an investigation.