Skip to content

AI for Mobility

Vehicles where the demand is, before it arrives.

We engineer AI for ride-share, micro-mobility, and fleet operators: supply-demand matching, dispatch, dynamic pricing, driver incentives, and vehicle positioning.

Built on your real network data and the oversight your operations team expects.

Discuss your dispatch problemSee how the system works

The operational reality

Riders request. Drivers move. Prices shift.

Idle miles are losses. Surge is complaints. Dispatch sits in the middle.

The right car. The right block. The right minute.

Felt by VP Operations, Heads of Dispatch, Driver Experience, and Network Planning, and the city managers running the daily ops.

  1. 01

    Supply logs on

    Drivers go online across the city. Each one has a preferred area, a shift length, and an earnings target for the day.

    Friction · Supply clusters where it is comfortable, not where demand will land.

  2. 02

    Demand arrives

    Riders open the app, request a trip, and expect an ETA they can trust before they tap confirm.

    Friction · ETAs are often guesses that do not survive the next traffic incident.

  3. 03

    Dispatch and matching

    The platform matches a rider to a driver, routes the driver to the pickup, and sets the price.

    Friction · Matching optimises the current trip; the next five trips get worse because the car went the wrong way.

  4. 04

    Mid-shift repositioning

    Drivers finish trips and need to be nudged toward the next pocket of demand through incentives or in-app suggestions.

    Friction · Repositioning advice is generic; drivers learn to ignore it.

  5. 05

    Charging, fueling, and end of shift

    Electric vehicles need chargers that are free, ICE vehicles need pumps, and drivers need to end their shift near home or a depot.

    Friction · Charging windows pull supply off the network at the wrong hour; shift ends cluster in the wrong zones.

Swipe the workflow

Where the work breaks

The friction is in the places nobody budgets for.

  • 01

    ETAs slip the moment the first incident hits the route.

    How we fix it · A system we build catches this before it costs you.

    Impact · Riders cancel; the matched driver has already deadheaded; the next match is slower.

  • 02

    Supply clusters where drivers want to be, not where demand lands.

    How we fix it · A system we build catches this before it costs you.

    Impact · Dead miles rise and driver earnings per online hour fall at the same time.

  • 03

    Dynamic pricing reads as punishment instead of signal.

    How we fix it · A system we build catches this before it costs you.

    Impact · Riders churn, regulators ask questions, and drivers do not trust surge to pay out.

  • 04

    Charging windows pull electric supply off the network at peak.

    How we fix it · A system we build catches this before it costs you.

    Impact · Chair time at the charger is paid for twice: once by the operator, once by the rider waiting.

  • 05

    Cancellation reasons are visible only in the weekly report.

    How we fix it · A system we build catches this before it costs you.

    Impact · By the time a pattern is clear, a week of trips has already been lost.

What we would build

Systems, not features. Each with its own job.

  • 01

    Live supply-demand matching

    Matching is per-trip; the network pays for the next five trips the match ruined.

    Who benefits · Dispatch teams, network planners, and the pricing team.

    Inputs
    Live GPS from active drivers, open ride requests, historical demand by hour and zone, live traffic feeds, and current incentive state.
    What the system does
    A matching model scores each possible pairing against the next thirty minutes of expected demand, not just the current trip, and routes drivers toward pockets of forecasted supply gaps.
    Output
    Trip assignments and reposition suggestions that improve the network state, with a per-decision reasoning log for the dispatch team.
    Benefit
    Dead miles fall, driver earnings per online hour rise, and the ops team can explain why a match looked unusual.
    Human stays here
    Dispatchers can override any assignment. Reposition suggestions are advisory; drivers are never routed into dangerous zones.
  • 02

    ETA accuracy you can quote with a straight face

    ETAs that miss by three minutes lose the rider at tap-to-confirm.

    Who benefits · Riders, drivers, and the operations team watching the complaint queue.

    Inputs
    Live traffic feeds, historical pickup variance by zone and time of day, driver type, and current incident reports.
    What the system does
    A per-zone, per-time-of-day model learns pickup variance from your own trip history and adjusts the quote in real time as the driver approaches.
    Output
    A quoted ETA with a confidence band, and in-app updates when traffic breaks the quote.
    Benefit
    Cancellation rate falls; rider trust in the quoted number holds across repeat trips.
    Human stays here
    A dashboard surfaces zones where the model is consistently wrong; the pricing team can retrain on recent weeks.
  • 03

    Driver repositioning that drivers trust

    Generic reposition nudges get swiped away. Drivers learn to ignore them.

    Who benefits · Drivers, driver-experience managers, and the incentives team.

    Inputs
    Each driver preferred zones, past acceptance of nudges, forecasted demand pockets, current incentive budget, and charging state for electric vehicles.
    What the system does
    The system picks the one nudge most likely to earn for this driver in the next thirty minutes, with an incentive if required, and never nudges into a zone the driver has declined before.
    Output
    A single, specific suggestion in the driver app, with the expected earnings uplift and the time window.
    Benefit
    Nudges stop being noise; driver earnings per online hour rise alongside utilisation.
    Human stays here
    Drivers can decline, mute by zone, or opt out entirely. Incentive spend is capped per zone, per hour, and audited.
  • 04

    Dynamic pricing that is explainable

    Surge that reads as punishment damages the brand and invites regulator attention.

    Who benefits · Pricing managers, policy teams, and city-ops leads.

    Inputs
    Live supply and demand, historical surge-off conversion by zone, rider price sensitivity, and the current regulatory price caps.
    What the system does
    Pricing moves within explicit caps and publishes a reason for each change: supply shortage in zone, incident on the main route, event ending nearby.
    Output
    Price adjustments with human-readable reasons, and a transparent audit log for city reporting.
    Benefit
    Surge-off conversion rises because riders understand why the number moved. Policy teams have a defendable record.
    Human stays here
    Hard caps are configured per city; the system refuses to price above them even if demand says it could.
  • 05

    Charging and fueling windows that respect the network

    Charging pulls electric supply off the grid at peak demand hours.

    Who benefits · Fleet managers, EV ops, and the driver-success team.

    Inputs
    Vehicle state of charge, charger availability, forecasted demand by zone and hour, driver shift state, and route to next charger.
    What the system does
    The system schedules charging windows during forecasted demand troughs, routes drivers to free chargers near their next trip, and reserves charger slots when the network predicts a crunch.
    Output
    A per-driver charging plan that respects both the shift and the network, and a city-level view for fleet ops.
    Benefit
    Charging stops colliding with peak; fleet earnings per vehicle rise without adding cars.
    Human stays here
    Drivers can override at any time; emergency low-battery states route to the nearest charger regardless of network state.

Show the system

What it could look like in your hands.

A design concept, not a shipped product. Interfaces like this get drawn out before any code lands, so the system reads back the way the people using it work.

dispatch / morning peak

Network view

A / HarbourB / MidtownC / West LoopD / AirportE / North HillV-104V-118V-127V-139V-152V-161V-172

Stylised network grid, not a real map.

Synthetic data. This is a design concept of how a live dispatch view, a stylised network grid, and a request queue could sit together in a city ops console.

End-to-end workflow

From the trigger to the outcome.

A representative trip path, from a rider tap to a completed drop. Automated stages run in milliseconds; human stages remain explicit and reviewable.

  1. 01

    Rider taps request

    The app sends the request with pickup, destination, and vehicle type. The matching model opens a candidate set within the service radius.

    Automated
  2. 02

    ETA quoted

    The ETA model combines live traffic, pickup variance for this zone and hour, and the candidate driver route; the quote carries a confidence band.

    Automated
  3. 03

    Match chosen

    The matcher picks the pairing that scores best for the next thirty minutes of forecasted demand, not just the current trip.

    Automated
  4. 04

    Driver nudged if needed

    If the match pulls the driver out of a dense zone, the system flags the cost and suggests a nearby pairing instead.

    Guardrail
  5. 05

    Dispatcher visibility

    City dispatchers see every unusual match, override anything they want to, and keep a per-decision reasoning log.

    Human in loop
  6. 06

    Trip runs

    Live routing adjusts to incidents; the ETA is updated in-app for the rider and the driver, and the surge price is held once the trip starts.

    Integration
  7. 07

    Reposition after drop

    The driver gets one specific reposition suggestion for the next thirty minutes, with expected earnings and a decline-and-mute option.

    Automated

How exceptions are handled

  • If a zone hits the regulatory price cap, pricing refuses to move further regardless of demand.
  • If a driver declines a reposition zone, the system never nudges them into that zone again that shift.
  • If a vehicle drops below emergency state of charge, charging routing overrides any network objective.
  • If a request is in a geofenced no-service area, the system declines rather than taking the trip and failing it later.

How it is engineered

Built on your stack, not ours.

Design choices that let a mobility network run under real load, under real regulatory scrutiny, and under driver and rider trust.

01

Live data plane

Low-latency ingestion for driver GPS, ride requests, and incident feeds, with per-city partitioning and bounded staleness guarantees for matching.

02

Matching and pricing models

Matching is a thirty-minute horizon problem, not a one-trip problem. Pricing has hard caps and publishes a reason for every change.

03

ETA model

Trained per city, per zone, per time of day, on your own trip history. Confidence bands are first-class; the app shows the quote the system actually believes.

04

Driver and rider identity

SSO through your existing identity provider for ops users; driver and rider identities are tenant-scoped and audited on every lookup.

05

Data boundary

Personal data falls under GDPR and CCPA; retention windows are configurable, model inference runs with no retention, and no training on your rider data.

06

Observability and evaluation

Every match and every nudge logs its inputs, model version, and outcome; an evaluation harness watches ETA accuracy, dead-mile rate, and cancellation drift.

What the business will measure

Numbers the operator already watches.

We agree on metrics and baselines before building. These are the numbers an operations team usually watches when deciding whether a mobility system is working.

  • 01

    Utilisation (paid time on online time)

    Baseline today

    Current trip-time divided by online-time per driver, per city, per hour.

    How it moves

    Thirty-minute-horizon matching plus reposition nudges keep more drivers on paid trips in each shift block.

  • 02

    ETA accuracy

    Baseline today

    Share of quoted ETAs within a tolerance band at pickup.

    How it moves

    A per-zone, per-time-of-day model learns pickup variance from your own history and updates the quote as the driver approaches.

  • 03

    Dead miles

    Baseline today

    Miles driven online without a paying rider, per vehicle, per shift.

    How it moves

    Reposition suggestions move drivers toward forecasted demand pockets instead of generic hotspots.

  • 04

    Driver earnings per online hour

    Baseline today

    Total driver earnings divided by online hours, by city and shift block.

    How it moves

    Fewer dead miles plus targeted incentives raise earnings without raising rider price.

  • 05

    Rider cancellation rate

    Baseline today

    Share of requests cancelled before pickup, by zone and time of day.

    How it moves

    Honest ETA quotes and faster matching reduce the moments where a rider taps cancel.

Human in the loop

Oversight, safety, and the regulatory posture

Where the humans stay in control.

A mobility network answers to riders, drivers, cities, and regulators every day. The system is designed around what each of them expects.

  • 01

    TNC and DOT posture

    City and state TNC rules, DOT hours-of-service where applicable, and ADA accessibility requirements are configured per market and enforced at the dispatch layer.

  • 02

    Price caps and transparency

    Hard price caps per city; every price change publishes a machine-readable reason; a reporting view backs city audits.

  • 03

    Driver classification

    The system does not take actions that implicitly reclassify a driver. Nudges are advisory, incentives are opt-in, and schedule control stays with the driver.

  • 04

    Rider and driver data

    GDPR and CCPA retention windows are configurable; personal data is tenant-scoped; no training on rider or driver personal data without a separate written agreement.

  • 05

    Safety overrides

    Emergency low-battery, incident proximity, and no-service geofences override any network objective. A rider or driver safety flag halts automation on that trip.

  • 06

    Attribution and audit

    Every match, every nudge, every price change logs the model version, the inputs, and the dispatcher who was in session. Audits can reconstruct any decision.

Proof

Work we have shipped, and the shape of what we build.

Real engagements where we can speak to them, and representative use cases where we cannot.

  • Use case

    Thirty-minute-horizon matching

    A proposed design: match a trip against the next thirty minutes of forecasted demand rather than the current request alone, with a per-decision reasoning log for dispatch.

  • Use case

    ETA quotes with a confidence band

    A proposed design: a per-zone, per-time-of-day ETA model trained on your own history, quoting a window the system actually believes, updated live as the driver approaches.

  • Use case

    Reposition nudges that drivers accept

    A proposed design: one specific nudge per driver per block, with expected earnings and decline-and-mute, so drivers stop learning to ignore the app.

How the build runs

Scoped tightly, shipped in phases.

Fixed price per phase, approved before the phase starts. You own the code, the models, the data, and the deployment.

  1. 01

    Discovery

    Two weeks. We ride-along a shift, map the real dispatch workflow against your platform, and agree on the metrics we will move and how we will baseline them.

  2. 02

    Prototype on real data

    Four to six weeks. One city, one shift block, one proof of mechanism. Shadow-matched against your live platform; we measure against the baseline.

  3. 03

    Production rollout

    Eight to twelve weeks per city. Live data integrations, SSO, regulatory configuration, audit trails, evaluation harness, and the dispatcher workflow your ops team signed off on.

  4. 04

    Handover

    You get the full source, the runbooks, the evaluation suite, and a two-week walkthrough with your engineering, ops, and policy teams.

  5. 05

    Optional ongoing support

    A fixed-term support agreement for model-drift monitoring, regulatory configuration changes, and seasonal retraining. Never a retainer dependency.

Common questions

Answers before the first call.

01Can this run alongside our existing dispatch platform?
Yes. We often start as a decision-support layer that reads from your platform and writes suggestions back, with a dispatcher override on every call. When the measurement proves out, we expand to the surfaces that need to act automatically.
02How do you handle driver classification risk?
The system never takes actions that implicitly reclassify a driver. Nudges are advisory, incentives are opt-in, and schedule control stays with the driver. Your policy team configures what is advisory and what is required.
03How do you handle price caps and city audits?
Hard caps per city are enforced at the pricing layer; every change publishes a machine-readable reason; a reporting view backs city audits and your own transparency reporting.
04What about electric fleets and charging?
Charging is scheduled against forecasted demand troughs where possible, with safety overrides for low state of charge. Charger slots can be reserved when the network predicts a crunch.
05What data do you need to start?
A representative sample of trip history, live driver and request feeds in a staging environment, and your current ETA and pricing baselines. We work with what you have; we do not require a clean warehouse to begin.
See the other details on the FAQ page

Next step

A thirty-minute conversation. Bring one shift block that loses you utilisation today, and we will walk through what the first phase would look like, where the measurements come from, and what has to be true for your policy team to approve it.

Discuss your dispatch problem

Helpful to have on the call

Helpful to have on the call: your current platform, one city with a utilisation or ETA pain point, and the person who owns the metric you would like to move.

Explore

A different problem in every sector, one engineering standard underneath.

Featured · AI for healthcare

Healthcare

Why is your clinician still charting at midnight?

Your clinicians are charting until midnight and your front desk is drowning in prior auths. We build AI that writes clinical notes automatically, triages patients to the right care faster, and finds any record with a simple question, so your people spend their hours on patients instead of paperwork.

See AI for healthcare
stallwart / healthcare

Live run

Healthcare

Running
as of nowhealthy
See every industry we build for

An AI-First Engineering Company

Get a price in one call.

One 30-minute call. You leave with an architecture, a fixed price, and a start date. No charge, and no slide deck.

Booking now for December 2026

Book a callSee how it works