Skip to content
Case study · Student transportDelivered

Student transport development: two apps, two portals and an automated trip builder

Trust-EdUnited StatesEnd-to-end buildFour years to production · live today

1,203

Trips completed in Trust-Ed's published Ohio pilot

50,153

Miles driven across that pilot, with zero incidents

Live

In production and serving families today

One vehicle, four school districts, and each district owes only for the miles its own students actually rode.

Trust-Ed moves students who fall outside standard school transportation — special-needs, McKinney-Vento, out-of-district — using vetted educators rather than a contracted bus fleet. We built the platform end to end: mobile apps for parents and drivers, a school-district portal and a franchise portal, and an automated trip builder that routes each run, prices it against live gasoline costs, watches how it was driven, and splits the bill across every district aboard. It is live and serving families today.

01

The challenge

Special-needs and out-of-district student transport is a shared-cost problem wearing a logistics costume. A single vehicle can carry children who belong to several different school districts, and each district is only liable for its own students' share of that trip. Get the apportionment wrong and you are either over-billing a public body or absorbing the cost yourself — and neither survives an audit.

Building the trips by hand does not scale either. Someone has to decide which educator drives which children, in what order, over what route — and the answer changes with every enrolment, every absence and every fuel price. Do that on a spreadsheet and the margin disappears into the arithmetic.

Meanwhile four different people need the same trip to make sense to them at once: a dispatcher assigning runs, an educator-driver who needs the next stop rather than a spreadsheet, a parent who wants to know their child was collected without telephoning the office, and an administrator who needs the month's report to reconcile against a legal obligation.

02

The solution

One platform over a shared services layer, with the surface each audience actually needs rather than a single interface stretched over all of them.

A

Two mobile apps, for the two people in the car

The parent app gives live tracking of the run their child is on, pickup and drop-off alerts, and sight of the driver's credentials — because Trust-Ed's whole proposition is that the driver is a vetted educator rather than an anonymous contractor, and that claim has to be visible. The driver app is built for the windshield: trip acceptance, turn-by-turn navigation, earnings, and biometric login because it holds student data. Both are Flutter, so one team ships both stores.

B

Two portals, for the district and the franchise

The school-district portal is where administrators enrol students, manage drivers, build trips and pull compliance reports. The franchise portal sits above it, letting an operator run the programme across several districts at once — its own drivers, its own routes, its own accounting — which is what lets the model expand into a new region without a new system.

C

An automated trip builder that prices what it plans

Rather than assigning runs by hand, the trip builder assembles them: matching available educator-drivers to the students who need collecting, sequencing multi-student routes, and routing them through the HERE SDK. Crucially it prices as it plans — live gasoline costs feed the trip's cost model, so a route's economics are known when it is built rather than discovered at the end of the month.

D

ZenDrive, because how it was driven matters

A platform carrying vulnerable children cannot treat a completed trip as a successful one. The ZenDrive SDK measures driving style and behaviour on every run — the acceleration, braking and handling that indicate how the journey actually went — so safety is something Trust-Ed can observe across its roster rather than infer from the absence of complaints.

E

The billing engine, and why rounding is the hard part

The core of the system splits a shared trip across districts by passenger-miles: each district pays for the distance its own students actually travelled on that vehicle. The division is arithmetic; the difficulty is that the parts must sum back to the whole. We built the apportionment with cent-accurate rounding, so district shares always reconcile exactly to the trip's total cost, with nothing lost or invented in the last decimal place. Driver earnings flow out of the same engine on a 1099 contractor structure.

F

A trail the district can hand to an auditor

Every trip generates its own record, aligned to McKinney-Vento, ESSA, SPED/IEP and FERPA expectations. For the district buying the service, that report is as much the product as the ride is — it is the artefact that proves a legal obligation was met.

03

How it was built

Two apps, two portals and the services beneath them, delivered and maintained by one small senior team on the same pipeline as everything else we ship: agents generate the predictable volume, and senior engineers own the parts that carry risk. On a system that computes money owed by public bodies, the billing logic is exactly the code a named human reads line by line — written against acceptance criteria agreed up front, not retrofitted to whatever the implementation happened to do. It runs on AWS Lambda behind load balancing and a CDN, so a service used hardest at the start and end of every school day scales with the day rather than with the peak.

04

Results

The platform went from concept to production and is live today, serving families, districts and the educators who drive for them — a multi-year relationship rather than a project handed over and forgotten. In the Ohio pilot Trust-Ed publishes for 2024–25, it managed 1,203 completed trips over 50,153 miles with zero incidents, and paid roughly $70,000 out to the educators who drove them.

In my 20+ years building technology solutions, I've never had better customer service.
Giancarlo Newsome Business Modernization Consulting, United States
05

Common questions

Why not just split the cost of a trip evenly between the districts?

Because it would be wrong, and provably so. A student riding four miles and a student riding twenty do not represent the same cost, and the district asked to fund the difference will ask why. Passenger-miles apportionment is defensible in an audit; an even split is a number nobody can justify.

Why does a transport platform need to know the fuel price?

Because the trip is the unit that gets billed, and fuel is the part of its cost that moves. Feeding live gasoline prices into the trip builder means a route's economics are known when it is planned rather than reconciled afterwards — which is the difference between pricing a service and hoping about it.

Do you keep running what you build?

Often, yes. Trust-Ed is a multi-year production relationship, not a build-and-hand-over. We can operate and evolve a system after launch, or hand it to your team with the tests and documentation to own it themselves.

Most of what we build is under NDA — yours would be too, unless you told us otherwise. Send the requirement and you get back a functional specification, at no charge.