Mobility platforms, built for the two numbers that fight each other.

Matching, pricing and driver economics engineered together, because rider wait time and driver utilization move in opposite directions and every serious decision in this sector is a trade between them. Eight mobility platforms already in production, and a custom engineering team for everything beyond them.

Custom build Starting from a shipped platform

Custom build - 2 to 8 weeks, scoped

Licensing
Matching
Pricing and payments
Safety
Supply balance
Launch

Ready-made platform - 6 working days

Rebrand, deploy, live

Six working days is the launch timeline for a ready-made platform as it ships - branded, deployed and live on infrastructure you own. Sector work beyond that, and the custom track above, is scoped and quoted in writing before anything starts. Both tracks are the same engineering team. Every figure on this page is defined on our facts page.

What a mobility build actually contains

The sequence below is where mobility platforms are won or lost. Every phase names what it requires and, where one exists, the shipped platform that removes it.

Mobility has a property that makes it unusually unforgiving: both sides of the marketplace are live at the same moment, in the same place, with seconds of tolerance. A rider will abandon after a wait they consider unreasonable, and that threshold is shorter than most teams assume. A driver who spends too much of their shift unpaid will work for someone else next week. The platform is continuously balancing those two, and every pricing, matching and incentive decision moves both.

Three of the seven phases have no shortcut. What a shipped platform removes is the middle: matching, pricing and the payments stack.

01Weeks 1-2

Market, licensing and the vehicle model

Mobility is regulated locally rather than nationally, and the rules differ between cities in the same country. Operating licences, driver permits, vehicle categories, insurance minimums and whether your model is even permitted are the first constraints, and they shape the product rather than sitting beside it.

The vehicle model follows from that. A platform serving licensed taxis, private hire vehicles and peer-to-peer car sharing needs three different compliance profiles, three insurance positions and three answers to who is responsible when something goes wrong.

The output is a market entry position: which cities, under which permission, with what your platform must prove about every driver and vehicle before dispatch.

Operating licenceVehicle categoriesInsurance minimumsDriver permits
No shortcut here. Licensing is the same constraint on both tracks, and building before you know your permission is how platforms get switched off in a market.
02Weeks 2-4

Matching and dispatch

Nearest available driver is the intuitive rule and it is close to the worst one. It strands drivers who happen to be near a low-demand area, ignores where the trip will end, and produces a distribution of wait times that is fine on average and terrible at the tail.

Better matching considers where the driver will be afterwards, whether a slightly longer pickup produces a materially better trip, and whether waiting three seconds for a closer driver to become free beats assigning now. Batched matching over a short window outperforms greedy assignment, and the window length is a tuning decision per city.

Location itself is a hard problem underneath this. Positions arrive irregularly, tunnels and dense buildings break them, and a matching engine that trusts every reported coordinate will dispatch to a driver who is actually a street away.

Batched matchingDestination awarenessLocation qualityWait-time tail
Already builtDispatch with batched matching, destination awareness and location smoothing.
03Weeks 3-5

Pricing, surge and driver earnings

Pricing in mobility is a supply instrument, not a revenue setting. Raising prices when demand exceeds supply does two things at once: it reduces requests and it attracts drivers into the area. Both are necessary, and a platform that cannot do it will simply fail to serve peak demand.

It is also the most scrutinized mechanism you will operate. Surge during emergencies, price differences between neighbourhoods and opaque driver earnings all attract regulatory and press attention, so the rules need to be explicable and the caps deliberate.

Driver earnings deserve equal engineering weight. A driver who cannot reconstruct why a trip paid what it did will assume they were shortchanged, and that belief spreads through driver communities faster than any communication you send.

Surge rulesZone pricingEarnings breakdownCaps and ethics
Already builtDynamic pricing with zone rules, caps and driver-readable earnings breakdowns.
04Weeks 4-7

Trip lifecycle, payments and disputes

A trip is a state machine that runs in the physical world, which means it disagrees with reality regularly. Riders cancel after a driver has travelled. Drivers end trips early or late. Phones lose signal in the middle. The fare has to be computable and defensible in all of those cases.

Payment adds its own timeline. Cards are pre-authorized then captured on completion, cash remains significant in many markets and creates a settlement flow in the opposite direction, and wallets need topping up and refunding. Tolls, waiting time, cleaning fees and tips each attach differently.

Disputes are frequent and low value individually, which means they have to be resolvable from trip data rather than by investigation. Route, timing and fare breakdown retained per trip is what makes that possible.

Cancellation policyCash settlementFare componentsTrip evidence
Already builtTrip lifecycle with cash and card settlement, fare components and retained trip evidence.
05Weeks 6-7

Safety, verification and insurance

Mobility carries physical risk to real people, which puts safety above every other consideration in this sector. Driver identity, licence validity, vehicle roadworthiness and insurance are all checked before dispatch and re-checked on a schedule, because every one of them expires.

In-trip safety is a product surface of its own: share-trip, an emergency path that works with one hand, and the ability to identify a vehicle before entering it. These are not features to add after an incident.

Account sharing is the failure mode that matters most. A verified driver lending their account to an unverified person defeats every check you performed, so periodic re-verification against a live capture is the control that actually holds.

Document expiryRe-verificationEmergency pathIncident handling
No shortcut. Shipped platforms carry the verification and safety machinery, but your jurisdiction's requirements and your insurer's terms are yours to meet.
06Weeks 7-8

Supply balance and city economics

A mobility marketplace works or fails on liquidity in a defined area, and liquidity is local. Coverage across a whole city with thin density everywhere is worse than density in three neighbourhoods, because wait times in a thin area are long enough to lose riders permanently.

This is where incentives get designed rather than improvised. Guarantees, peak bonuses and repositioning nudges all cost money and all change driver behaviour, and their effect has to be measurable per zone and per hour rather than assessed by feel.

Zone densityIncentive designUtilizationUnit economics
Already builtZone-level supply tooling with incentive management and utilization reporting.
07Weeks 7-8

Launch and day two

One city, and within it a small number of zones with real driver density before any rider acquisition spend. The most common way to waste a launch budget in this sector is to advertise across a city your supply cannot serve.

Day two is safety incidents, fare disputes and driver earnings queries, all of which arrive immediately and none of which can wait for a release cycle. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates.

Zone launchDriver densityIncident responseDay two support
No shortcut. Same on both tracks. A shorter build does not shorten driver recruitment, which is the real constraint on when you can open.

Want any of these phases costed against your city and vehicle model?

Book a technical call

Where a trip actually goes

Every mobility platform is this sequence with different names on the boxes. The hops are easy. What separates a platform riders keep using from one they delete is the tail of the wait-time distribution, and what happens when a hop fails.

Trip lifecycle, request to fareRider to settlement, with the failure mode at every hop
RequestMatchPickupIn tripFare Rider requestsPatience is short Driver assignedBatched, not nearest Driver arrivesUnpaid time for them JourneySignal drops happen Fare settledCard, cash or wallet Driver declines, or nobody accepts Re-match silently and fast, or the rider opens another app. Failure modes No supply nearbyRepeated declinesRider cancels lateSignal lost mid-tripFare disputed
Standard pathWhere riders are lost

Repeated declines are the failure riders experience as "the app is broken". Each decline is invisible to them; what they see is a spinner that lasts a minute. Re-matching has to be fast and silent, and a driver who declines frequently in a zone is a supply signal rather than an individual problem.

Why wait time and utilization pull against each other

Every mobility platform manages one balance, whether or not it names it. More drivers on the road means shorter waits for riders, which is what retains demand. It also means each driver spends more of their shift waiting, which lowers their earnings per hour and is what loses supply. The same lever moves both, in opposite directions.

This is why pricing is a supply instrument rather than a revenue setting, and why incentives are engineering rather than marketing. Raising price at peak suppresses some demand and pulls drivers in, moving both sides toward each other. Guarantees in a thin zone raise driver willingness to be somewhere unprofitable. Both cost money and both need measuring per zone and per hour, because the balance is local and changes through the day.

Want your supply balance modelled against your launch zones?

Talk to an engineer

Eight operators, eight different builds

"Mobility" is not one buyer. The regulatory position, the asset model and the matching problem change completely between them.

Ride-hailing

Drivers with their own vehicles, matched in real time. Wait-time tail and driver utilization are the two metrics that decide whether the market works, and both are local.

4 shipped platforms

Taxi fleet digitization

Existing licensed fleets moving to an app. The regulatory position is already solved; the hard parts are driver adoption and integrating with meters and dispatch systems already in place.

3 shipped platforms

Peer-to-peer vehicle sharing

The asset belongs to another individual. Verification, damage evidence at handover and insurance during the rental period dominate, and the matching problem is scheduling rather than real time.

1 shipped platform

Micromobility

Bikes and scooters with no driver at all. The problems move to fleet distribution, battery and charging operations, and vehicles that end up somewhere they should not be.

Custom build

Intercity and scheduled transport

Fixed routes and departure times, seat inventory rather than vehicle matching. This is closer to travel booking than to ride-hailing and should be built that way.

2 shipped platforms

Corporate and employee transport

Contracted routes, rostered pickups and a company paying rather than a rider. Billing, attendance records and safety reporting to an employer are the product.

2 shipped platforms

Super apps

Rides alongside delivery, payments and more, sharing one identity and wallet. The engineering challenge is shared infrastructure without one service's incident affecting the others.

2 shipped platforms

Fleet and logistics operations

Owned vehicles and employed drivers, where the goal is utilization and cost per kilometre rather than marketplace liquidity. Routing and maintenance replace matching.

Custom build

Six of the eight can start from something already running. Two are custom builds because nothing off the shelf carries the domain properly, and we would rather say that than sell you an adaptation that fights you for two years.

Not sure which of these you are, or you sit across two of them?

Book a scoping call

How the work actually runs

Six stages, the same on both tracks. What changes between a custom build and a platform adaptation is how long stage three takes, not whether the other five happen.

01
Stage

Scoping against your city and permission

We start from the city you are launching in, the licence you hold or are pursuing, and the vehicle and driver model that permission allows, because mobility is regulated locally and those three decide the architecture before any preference does. Building before the permission is settled is how platforms get switched off in a market.

Ends withWritten scope: operating permission, vehicle categories, insurance position, and the launch zones rather than the whole city.
02
Stage

Architecture and the balance levers

Matching, pricing and incentives are designed as one system because they move the same two numbers. Surge rules, zone definitions and guarantee structures become configuration rather than code, since the balance is local and changes through the day, and tuning it should never require a release.

Ends withZones defined, pricing and incentive rules held as data, and a fare model that reconstructs per trip.
03
Stage

Build against city-shaped data

Mobility platforms fail on thin supply and bad location data, so test environments carry the real shapes: zones with two available drivers, positions that jump between buildings, signal lost mid-trip, repeated declines, and cancellations after a driver has already travelled. Simulating a dense, well-connected city proves nothing about the one you will launch in.

Length varies by track
Ends withTest data carrying thin zones, degraded location, mid-trip signal loss and repeated driver declines.
04
Stage

Safety, compliance and payments validation

Driver and vehicle verification proven against real documents with expiry blocking dispatch, the emergency path tested end to end, and card tokenization keeping PCI scope small. Our platforms arrive with a VAPT and compliance document, so external review starts from a documented baseline.

Ends withA VAPT and compliance document, expiry blocking dispatch, and the in-trip safety path exercised.
05
Stage

Driver onboarding and zone seeding

Real drivers, onboarded through the real flow, concentrated into the launch zones rather than spread across the city. This is where verification requirements meet the documents drivers can actually produce, and where you learn whether your onboarding asks more than your supply will tolerate.

Ends withA verified driver cohort with density in the launch zones, payouts configured and incentives live.
06
Stage

Launch and day two

Zones open before city-wide marketing, with wait-time tail and driver utilization watched hourly through the first weekends. Both move fast and both tell you whether the balance is right. Sixty days of dedicated support, six months of priority bug resolution, twelve months of updates.

Ends withSixty days dedicated support, six months priority bug resolution, twelve months of updates.

Want this sequence mapped against your city and licence position?

Book a technical call

Eight mobility platforms already in production

Every one ships with full source-code ownership, deployed on your infrastructure under your brand. Adapt one, or use it as the reference architecture for a custom build.

They fall into three groups, and which group you start from matters more than which name you recognise. Ride-hailing platforms carry real-time matching, surge and driver earnings, which is the hardest engineering in the sector. Super apps add shared identity and wallet across several services, where the challenge is isolation between them. Asset sharing platforms carry verification, handover evidence and rental-period insurance, and their matching problem is scheduling rather than real time.

What this sector requires

Matching beyond nearest

Batched assignment over a short window, aware of where the trip ends and how good the location data actually is. Nearest-available is intuitive and produces the worst wait-time tail.

Pricing as a supply lever

Surge that suppresses demand and attracts drivers simultaneously, with deliberate caps and rules you can explain publicly, because this is the mechanism you will be asked about.

Reconstructable earnings

Every fare broken down so a driver can see why it paid what it did. Drivers who cannot reconstruct a number assume they were shortchanged, and that belief spreads faster than any message you send.

Verification that expires

Licence, insurance and vehicle checks re-run on a schedule, with expiry blocking dispatch, plus live re-verification against account sharing which defeats every other control.

A working safety path

Share-trip, one-handed emergency access and vehicle identification before entry. These belong in the first release, not in the response to an incident.

Zone-level economics

Density, utilization and incentive cost measured per zone and per hour, because liquidity is local and a city-wide average hides exactly the areas where you are failing.

Want to open any of these platforms and look inside before deciding?

See the live demos

Every safety control fails to one thing: a shared account

A platform can verify a driver perfectly at onboarding and still put an unverified person in a car with a passenger. The control that closes it is the one most platforms add last.

Driver verification and re-verificationOnboarding to dispatch, and the control that survives account sharing
OnboardingOngoingEach shift Identity and licenceChecked against the issuer Vehicle and insuranceRoadworthy, and covered Expiry monitoredBlocks dispatch, silently Live captureIs this the same person? What each control actually stops Identity check - someone using another person's documents at signup Insurance check - a vehicle carrying passengers without valid cover Expiry monitoring - a licence or policy that lapsed after approval Live capture - a verified driver handing their account to somebody else Only the last one survives a determined workaround, which is why it cannot be optional
Onboarding controlsThe control that holds

Account sharing is not an edge case in this sector; it is the predictable consequence of a valuable account and an applicant who cannot pass a check. Periodic live capture before going on shift is the only control that addresses it, and it belongs in the first release.

Want your verification and safety model reviewed against your regulator's requirements?

Talk to an engineer

Built custom when nothing off the shelf fits

The same team, working from zero. These are the capabilities we build into mobility platforms that no shipped product carries, because they are specific to how you operate.

Micromobility fleet operations

Vehicle distribution, battery and charging logistics, geofencing and the retrieval workflows that decide whether a scooter business is viable in a city.

Custom software development

Routing and fleet optimization

For owned fleets: multi-stop routing, shift planning and maintenance scheduling, where utilization and cost per kilometre replace marketplace liquidity as the objective.

Data engineering

Meter and dispatch integrations

For licensed fleets moving to an app: connections to the meters, radios and dispatch systems already in place, so digitization does not require replacing everything at once.

API development

Demand forecasting and repositioning

Per-zone, per-hour demand models that drive incentive placement and repositioning nudges, trained on your own trip history rather than a generic curve.

AI engineering

Corporate transport and billing

Contracted routes, rostered pickups, attendance records and invoicing to an employer, with the safety reporting a corporate client will require.

Backend engineering

Super app architecture

Shared identity and wallet across rides, delivery and payments, built so an incident in one service cannot take the others down with it.

Cloud and DevOps

Need something this list does not cover?

Ask about custom work

What we built, and what it delivered

Three deployments in this sector, described by what was actually built rather than by a metric we cannot show you the working for.

Ride-hailing

City launch with zone-level incentives

Batched matching with destination awareness, surge held as configuration with published caps, and incentive spend measured per zone and per hour rather than assessed by feel.

Fleet digitization

Licensed taxi fleet moving to an app

Integration with existing meters and dispatch, driver onboarding designed around documents the fleet already held, and cash settlement running alongside card.

Asset sharing

Peer-to-peer vehicle rental

Owner and renter verification, condition evidence captured at handover in both directions, and insurance cover scoped to the rental period rather than the account.

We describe these by scope rather than by outcome metrics, because the numbers that matter to you are your own and we would rather model them with you than quote someone else's.

Want to speak to a reference operating in your model?

Request a reference

Written on this sector

Longer pieces on the problems above, written by the engineers who build these platforms.

If a question here is not covered, the fastest route to an answer is a call with the engineer who would run your build.

Want these as a briefing pack for your board or engineering team?

Request the pack

We launched across the whole city because it looked ambitious. Our wait times were terrible everywhere instead of good somewhere, and we never recovered those first riders.

The failure pattern this page is built around

That gap is the whole reason this page exists. Forty client testimonials sit on the site with names, titles and companies attached, and none of them are invented.

Questions mobility buyers actually ask

The ones that come up in the first call, answered as we would answer them there.

Can we really launch in six working days?

Yes, for a shipped platform as it comes. It does not cover your operating licence or driver recruitment, which run on the regulator’s and the market’s timelines rather than ours.

Do we own the source code?

Yes, in full, deployed on your infrastructure. No per-trip licence, no per-driver fee, no runtime dependency on us.

Should we launch across the whole city?

No, and this is the most common expensive mistake in the sector. Density in a few zones produces short waits and riders who return; thin coverage everywhere produces long waits and riders who do not.

How is surge handled?

As a supply instrument with explicit rules and caps, held as configuration. It is the mechanism you will be asked about publicly, so it needs to be explicable rather than emergent.

Can drivers see how their fare was calculated?

Yes, broken down per component. A driver who cannot reconstruct a number assumes they were shortchanged, and that belief spreads through driver communities faster than any correction.

Do you support cash payments?

Yes, including the reverse settlement flow it creates where drivers owe the platform rather than the other way around. In many markets cash is still the majority of trips.

How do you handle account sharing?

With periodic live capture before a shift, checked against the verified identity. It is the only control that survives a determined workaround, and it belongs in the first release rather than after an incident.

What happens when a driver cancels after accepting?

Silent, fast re-matching, because the rider experiences repeated declines as a broken app rather than as individual decisions. Frequent declines in a zone are treated as a supply signal.

Can we run rides and delivery on one platform?

Yes, and the super-app model is well supported. The engineering care goes into isolation, so an incident in one service does not take the others down.

What about insurance?

Verified at onboarding, monitored for expiry, and scoped correctly for your model - cover during a rental period differs from cover for a driver carrying passengers. We build to your insurer's terms rather than to a default.

What does support look like after launch?

Sixty days of dedicated support, six months of priority bug resolution and twelve months of updates. Safety incidents, fare disputes and earnings queries all arrive immediately, so that window matters.

What if we are not ready to build yet?

We will say so. If your operating permission is unsettled or you cannot recruit drivers into two zones, a platform will not solve either, and we would rather tell you that than scope work you cannot use.

Question not answered here?

Ask us directly

Tell us what you are building.

Bring the city and the licence position. We will tell you honestly which track is right - including when the answer is that you do not need us yet.

A first call takes about thirty minutes and covers four things

01

Licence position

What you hold or are pursuing, and in which cities.

02

Vehicle and driver model

Owned fleet, licensed drivers, or individuals with their own cars.

03

Launch zones

Where density is achievable, rather than where coverage looks impressive.

04

Existing systems

The meters, dispatch and payment stack a platform must fit into.

Those four answers are usually enough for us to tell you which track fits, roughly what it costs, and whether your launch plan is spread thinner than your supply can serve. If the honest answer is that your licence needs to settle first, we will say that instead of scoping work you are not ready to use.