Get started
A yellow school bus on the highway, seen from behind

School district

Route the buses. Run the district.

Curb-side-aware school bus routing that never puts a student on the wrong side of the street, bell-time AM and PM runs planned from each school, and the workflow, forms, and audit substrate for everything else the transportation office owns.

Who this is for

K-12 district transportation directors, routing coordinators, and the back-office team that plans bus runs, fields parent requests, and answers to a board. You run somewhere between a handful and a few hundred buses across one or more schools with staggered bell times, and your current stack is some mix of a legacy routing package, a pile of spreadsheets, and a paper map on the wall.

This page is for the moment you're evaluating a replacement for that stack — or looking for the operations layer underneath it that the routing package never gave you.

What ships today

  1. What's currently shipped

The flagship for this vertical is the School Bus Router, riding on the free Logistics core with Forms and Workflows alongside it.

School Bus Router

The flagship app for this vertical. Students board and alight on the side of the street they live on — the router prefers a same-side stop and only falls back to a crossing pickup as a last resort you can tune. AM and PM runs are anchored to each school's bell times. Every run moves Draft → Assigning → Optimizing → Proposed → Approved → Published.

Learn more

Workflows

The same finite-state-machine engine the router runs on is yours for any district process — transfer requests, incident reports, driver check-ins. Every transition is an append-only audit record a board member can read.

Learn more

Forms — free

Public transportation-request and change-of-address forms with bot protection and a PDF copy on submit. Free forever — parent intake doesn't cost extra.

Learn more

Logistics core (free)

Schools, stops, students, buses, and the immutable event log — the shared substrate every routing run is built on. Free with every tenant.

Learn more

Extend without code

  1. How to extend with low-code

District routing is full of local policy — the maximum walk distance, the earliest a young student may be picked up, the approval a run needs before it's published. Most don't require an engineer:

  • Tune the crossing penalty per run (minutes). Each routing run carries its own crossing penalty and walk radius. Bump the penalty up for a route along a highway; relax it downtown. No code change.
  • Add an approval gate before publish (one hour). The run lifecycle already gates on a produced route; add a second reviewer state with an FSM guard so no run reaches drivers without a coordinator's sign-off.
  • Auto-notify on an unassigned student (an afternoon). A run surfaces every student left unrouted and every crossing pickup. Use the workflow engine to fire a notification when either list is non-empty, so a coordinator fixes it before the run goes out.
  • Model your own stop policy in the schema. Stops, students, and buses are schema-driven entities — add the fields your district tracks (hazard notes, shelter, guardian contact) without touching the router.

The low-code surface is bounded by what the schema can express. When the customization is broader than schema-shape, you're in customization territory — covered next.

Customize deeply

  1. How to make major customizations

In-house engineering

FastYoke ships a typed SDK (@fastyoke/sdk-next, @fastyoke/sdk-vue, plus a Rust crate for the kernel). For a district with an engineering bench, the SDK enables:

  • Integrations with the student-information system so rosters and addresses flow in without re-keying.
  • Custom parent-facing status surfaces built on the same run data the coordinator sees.
  • The ejection clause — take your compiled rules and per-tenant database with you whenever you want. No lock-in on public money.

FastYoke Partner engagement

For most districts, the right shape is a Partner engagement: schema authoring, FSM design for your specific run-approval flow, student-information-system import, and the first weeks of operator onboarding. See the Marketplace overview for the app catalog a partner assembles from.

Honest tradeoffs

What FastYoke isn't for school districts

  • Straight-line distance, not turn-by-turn. The router plans on great-circle distance between stops, not a live road network with turn restrictions and traffic. It sequences stops well; it is not a GPS navigation product for the driver's cab.
  • You place the stops. The district defines each stop and the curb it serves; the router assigns students and sequences runs. Automatic stop-clustering from student addresses is not in the first release.
  • No live vehicle tracking or parent app. The router plans runs; it does not stream a bus's GPS location or push arrival times to parents. Those are integrations, not built-ins.
  • One school per run, general-education loads. The first release routes a run against a single school and treats each student as one seat. Mixed-school loads, grade-tier separation, and wheelchair-lift capacity are roadmap, not shipped.

If those tradeoffs are deal-breakers, a dedicated transportation-routing suite may fit better today. FastYoke gives you the curb-side-aware routing core, the workflow engine, and the operations substrate for the district that wants one auditable platform rather than a routing silo.

Next step

Contact Sales

Browse the Marketplace