Should you build or buy Public Transit Scheduling & Operations?
Public transit scheduling and operations software builds bus and rail run cuts, driver rosters and vehicle schedules, then dispatches and tracks service in real time against the labor agreements and service plans that govern it. Transit agencies use it to keep buses and trains running on time with the operators available to run them.
Buy the scheduling optimizer and CAD/AVL; own the GTFS data and rider-facing tools.
Build it, buy it, or bridge?
When building makes sense
Agencies do build, but consistently around their vendor stack rather than in place of it. The MBTA's Customer Technology Department built Skate, a web-based dispatch tool that lets bus inspectors track as many as 1,000 buses and 800 operators at once, with a small team of two software engineers, a designer, a researcher and a product manager, launching in July 2019 after starting the project that April. It replaced outdated, hard-to-maintain proprietary hardware inspectors had been using in the field, and it now runs daily as part of their standard uniform kit. That is a genuinely successful build, and it is also a narrow one: Skate manages inspector visibility into service that vendor systems still schedule and dispatch. TriMet, another frequently cited example of in-house transit technology, helped originate and still runs the open-source OpenTripPlanner for rider trip planning, while its own scheduling job postings show staff still build timetables and driver rosters in HASTUS.
When buying makes sense
Buy the scheduling optimizer and the CAD and AVL system that dispatches your fleet, and keep your GTFS data and rider-facing tools on open standards where agencies have consistently succeeded building their own. HASTUS, Optibus and Trapeze all handle run-cutting and rostering against complex, agency-specific labor agreements, work that has to be right every day because the cost of getting it wrong is service that does not run. Even agencies known for strong in-house technology, like the MBTA with its own Skate dispatch tool and TriMet with its own OpenTripPlanner deployment, still rely on vendor systems for the scheduling and dispatch core itself. Follow that pattern: build the tools that make your data and your field staff's day-to-day work better, and buy the engine that has to honor your labor contract without error.
The desk read
Build-versus-buy analysis for Public Transit Scheduling & Operations is being written. In the meantime, the framework that drives every B4 call is on the B4 Index page.
Frequently asked
Have any transit agencies built their own operations software?
Yes, but for specific tools rather than the full stack. MBTA built Skate, an inspector dispatch app, with a small in-house team, and TriMet runs a production deployment of the open-source OpenTripPlanner for rider trip planning.
Do agencies that build their own tools still use vendor scheduling systems?
Yes. TriMet's own scheduling job postings show staff still build timetables and driver rosters in HASTUS even while the agency helped originate and runs OpenTripPlanner, and MBTA's Skate manages inspector visibility rather than replacing the scheduling and dispatch systems underneath it.
What makes run-cutting and rostering hard to replace with a custom build?
The software has to encode a specific labor agreement's rules correctly every time a schedule changes, and the operational cost of an error is service that does not run. That risk profile is why even technically capable agencies keep vendor systems for this piece.
What is a realistic build project for a transit agency's own engineering team?
Rider-facing tools and field applications built on open GTFS and GTFS-realtime data, following the MBTA Skate and TriMet OpenTripPlanner examples, rather than the run-cutting and dispatch core that has to honor labor agreements without error.