GET A QUOTE TfL↗
Licensing evaluation
Technical evaluation completed for London PHV operator licensing.
ENTERPRISE MOBILITY BUILD · 2017–2018
Engineering a London TfL-compliant ride‑hailing platform
The Miwhip case study
A London launch. Seven ways to ride. One platform built to manage the detail behind every booking.
For the entrepreneurs behind Crep Protect, we built Miwhip’s native apps, dispatch logic, payment flows and operator tools around the demands of London’s private-hire market.
Engineered behind the scenes.
- CLIENT
- Miwhip / Undercover Brothers LtdCrep Protect Group
- MARKET
- London, United KingdomPrivate-hire mobility
- DELIVERED
- iOS, Android & WebRider, driver and operator tools
- ENGAGEMENT
- Enterprise engineeringHistorical project · 2017–2018
01 / Project milestones
What the build brought together.
A case study of the systems delivered during the 2017-2018 engagement, from dispatch decisions to the infrastructure that underpinned them
03
Dispatch engines
Competitive, nearest-first and FIFO queue assignment.
07
Ride categories
From everyday journeys to executive and accessible travel.
03tiers
AWS architecture
Separate presentation, application and database layers.
Scope and milestones describe the project as built; this page is not describing a Miwhip service currently in operation.
02 / The client & the challenge
London needed more than a booking app.
Miwhip's founders were looking for a driver-first alternative in a market where driver welfare was often lacking.
The business is run by Imran Ahmed, Rizwan Ahmed and Nohman Ahmed. Its business model is a 15% commission, daily instant payouts, and driver caps that are designed to prevent drivers from being undercut.
We built the technical product that could support the new business model. Every booking needed to be checked against the operating boundary, the correct vehicle, an eligible driver and a payment that could be authorised before dispatch.
- The founders The team behind Crep Protect
Imran, Rizwan and Nohman Ahmed set out to build a driver-first alternative.
- The market London private hire
A demanding market, with TfL licensing for PHV operators.
- 2017–2018 Team Tweaks engagement
Native apps, dispatch logic, payment flows and operator tools.
Three challenges to solve at once
Hover or tap a challenge to open it.
Build for the licensing requirements.
Boundary Parameter Fencing, Verification of DVLA/PHV documents, auditing of logs and masked calls, were part of the compliance scope of the project.
- Boundary Parameter Fencing
- DVLA/PHV document verification
- Audit logs and masked calls
Make dispatch work across London.
Urban thoroughfares and congested international arrivals required separate management from airport parking lots. A single strategy could not be implemented at all places.
- Busy city corridors
- Airport holding areas
- Dispatch rules set by region
Keep seven services in one system.
Standard, luxury, group and wheelchair-accessible trips each required specific vehicle requirements without the need for separate booking platforms
- Standard and executive rides
- Luxury and group travel
- Wheelchair-accessible vehicles
April 2018A real business. A specific brief.
The engineering was driven by the operating model.
A driver waiting at Heathrow airport was facing a different scenario to a driver accepting requests in central London and these differences had to be represented in the dispatch rules, not in a manual workaround for the operator.
See how the dispatch engines worked
The modelDriver-first by design
A model built to protect driver earnings.
The software had to support the model the founders set out: a 15% commission, daily instant payouts and driver caps intended to protect driver earnings.
- 15% commission
- Daily instant payouts
- Driver caps
03 / Miwhip app architecture
Three tiers. One connected operation.
We kept apps and dashboards distinct from application services and databases. That made it easier for the team to manage ride requests, real-time locations and transaction records
AWS · London region / VPC / Elastic Load Balancing / Auto Scaling
AWS · London regionVPC · ELB · Auto Scaling
01
Presentation Apps & operator tools
- iOS app
- Android app
- Web dashboard
- Operator panel
02
Application Services & live messaging
- PHP / Apache
- XMPP engine
- Dispatch logic
- Auto-scaling EC2
03
Data Transactions & location logs
- MySQL
- MongoDB
- Live DB
- Archive DB
01 / Presentation
Apps & operator tools
Riders, drivers and the operations team each had their own interface, all talking to the same application services.
- Native iOS app
- Native Android app
- Back-office web dashboard
- Operator panel
Output → HTTPS / XMPP
02 / Application
Services & live messaging
Apache handled web requests, while the XMPP engine carried live messages between riders and drivers.
- PHP / Apache web server
- XMPP messaging engine
- Custom dispatch logic
- Auto-scaling EC2 instances
Output → Database connections
03 / Data
Transactions & location logs
MySQL held relational records and transactions; MongoDB handled high-volume geolocation logs.
- MySQL · users & transactions
- MongoDB · geolocation logs
- Live operational database
- Secondary archive database
Output → Operational + historical data
External integrations
- Adyen / Stripe
- Twilio
- Google Maps SDK
- VRM lookup
- DVLA / PHV checks
- Zendesk
Technology stack
- PHP
- HTML5
- Apache
- XMPP
- MySQL
- MongoDB
- AWS EC2
- ObjectRocket
- CloudFront
Capacity without a single fixed server
The system was deployed on AWS London infrastructure, making use of a Virtual Private Cloud, Elastic Load Balancers and Auto Scaling groups across Availability Zones. Web requests were processed by Apache while the XMPP engine transferred messages in real time between rider and driver.
Keep live data useful. Keep history available.
MySQL stored relational records and transactions, and MongoDB stored large volumes of geolocation logs. The documented retention policy moved older records out of the operational database via automated scripts.
1 yearActive ride logs
6 yearsArchive retention
Historical project configuration for audit access, not guidance on current TfL retention requirements.
Logical architecture reconstructed from the project documentation; not a deployment topology.
04 / Custom engineering
The decisions behind each ride request.
The visible journey was a simple, choose a ride, book and travel. Underneath, the platform was making decisions about where you were, whether you could travel, in what order you should be in the queue and how you should pay for the journey.
Three dispatch engines. Set by region.
Operators could switch the dispatch method for a geographic area from the back office.
The ride is broadcast to eligible drivers inside a defined radius. The first driver to accept the ride gets it.
The ride request is sent to the closest available driver based on real-time GPS tracking. If the first driver declines, the request is sent to the next closest driver.
The next available ride is given to the driver who has been waiting in a zone or holding hub the longest.
One passenger request. More than one available driver.
Example: a 4,000 m radius defines the broadcast area. The assignment is determined by the first acceptance.
LOCATIONGreater London
AREA / ZONEHeathrow Airport region
HUBAirport driver holding lotPriority queue for drivers within the hub
A boundary is not a queue.
The parameter for boundary fencing is for polygon drawing and for the enforcement of pickup only within areas where operation is licensed. The use of surge zones and airport hubs had separate design goals.
In the example at Heathrow, a smaller geofence was created that functioned as a holding lot for the drivers in queue, so that drivers in the hub had pickup priority over drivers outside the hub. The distinction of an operational boundary kept a city-wide geofenced area separate from a locally implemented dispatch rule.
- 01
LocationGreater London
- 02
Area / zoneHeathrow Airport region
- 03
HubAirport driver holding lot
Authorise the fare before dispatch.
Card.IO reduced manual card entry. The payment holds via Adyen payment holds linked the booking to the payment flow.
- 01
Choose a cardScan with Card.IO or use a saved card.
- 02
Place a holdAuthorise the estimated fare through the payment API.
- 03
Dispatch the driverContinue the booking after authorisation.
- 04
Capture paymentCollect the fare when the journey ends.
The source documentation references Adyen / Stripe integrations. This flow summarises the documented pre-authorisation approach.
Xmiwhip XRegular 4-seater hatchbacks and saloons.
EXmiwhip EXECExecutive saloons, including E-Class and 5 Series.
LXmiwhip LUXLuxury vehicles, including S-Class and 7 Series.
XLmiwhip XL6-seater SUVs and MPVs for large parties.
WAmiwhip WAVWheelchair-accessible vehicles with pivot seats or ramps.
BKmiwhip BLACKExecutive vehicles with black exteriors and interiors.
PKmiwhip PINKVerified female drivers for female passengers.
100A ride worth anticipatingA completed-ride tracker unlocks a free supercar experience at 100 rides.
Seven types of ride. For all kinds of needs.
Vehicles and drivers were managed within the same app.
Everyday→Executive & premium→Group & accessible
05 / UI & UX HIGHLIGHTS
Put the important choices where people need them.
The rider and operator interfaces brought the platform’s rules into everyday actions. The examples below explain the documented features; they are illustrative components, not original app screenshots.
Position card inside the frame •••• •••• •••• ••••
Camera-assisted entry01 / LESS TYPING
Card.IO scanning
The camera could read out card numbers and fill in payment fields, decreasing the amount of information a passenger had to enter.
02 / A CLEAR CHOICE
Driver preference
The camera could read out card numbers and fill in payment fields, decreasing the amount of information a passenger had to enter.
03 / OPERATOR CONTROL
Surge zones & radius controls
Polygon controls let the operator define both the zones where there are lots of customers and also where to limit dispatch.
04 / USEFUL DRIVER DETAILS
Plan a similar feature Driver badges
Badges surfaced verified qualifications, access supports, completed trips and driver ratings in a way that could be understood at a glance.
06 / GOVERNANCE & OPERATIONS
The work did not end at the booking screen.
A taxi booking app for TfL needed controls that operators could rely on.
In this case, it involved resolving technical licensing issues, providing data security, and enabling the operations team to keep the infrastructure under control.
The compliance scope described here relates to the original project and its licensing evaluation.
Discuss your compliance needsTechnical licensing evaluation
The project documentation records completion of the formal technical evaluation for TfL PHV operator licensing.
Private rider–driver calls
Twilio virtual proxy numbers routed calls between passengers and drivers without exposing their personal numbers.
24/7 infrastructure monitoring
Nagios/Zabbix monitoring scripts fed a Network Operations Center dashboard with CPU, latency and database health information.
From the project archive
People, places and vehicles from the Miwhip engagement.
From the project archive
People, places and vehicles from the Miwhip engagement.
07 / YOUR NEXT PROJECT
Your market has its own rules. Let’s build for them.
Thinking of building a on-demand ride hailing app? Let us know where you want to operate from, who is going to be your customer base and how you want to manage your drivers. We can help you translate your answers into a tangible product roadmap.
A USEFUL FIRST CONVERSATION
- 01
How you operate
What territories you operate in, types of rides you offer, driver guidelines, and the requirements to get a licence.
- 02
The technology you use
Apps, dispatching, payment processing, integrations and backend functionality
- 03
What matters most
What needs to get built first and what can come next
Partner with a mobile app development company in Chennai that has a track record of delivering software that meets the needs of global business.
