
FlowTransit is route planning and optimization software for public transit agencies and private operators. It models your network from the GTFS you already publish and your own ridership data, generates alternatives against your goals, and scores each one on travel time, ridership, coverage, and operating cost.
Most transit networks were never designed in one piece. Corridors were set decades ago, terminals were placed where land happened to be cheap, and each budget cycle trimmed or added at the edges. Very few agencies have had the chance to ask what the network would look like if it were drawn today.
Flow is built on a conviction about the bus. Rail lines and busways are fixed for decades once built; buses are the layer of the network that can move. They feed the trunk lines, cover the gaps between them, and follow demand as it shifts, and that interplay makes the whole network work. Flow makes that redrawing rigorous. It starts from your demand data: where riders get on and off, by stop and by hour, plus the origin-to-destination patterns inferred from that. That evidence drives the design, so the working question becomes which network serves those trips.
Ridership data is the evidence a redesign answers to. Every alternative is scored against the trips riders take today, by stop and by hour, before any line moves on the map.
Routes compete for the same riders and the same buses, so a change that helps one line can cost two others. Flow evaluates every edit at the network level, including the riders who shift between routes and the connections to rail and the other modes the buses feed.
Weights and constraints are yours, and every scenario reports the assumptions it was scored under. The optimizer only searches within them, planners make the final call, and any generated network can be edited by hand.
Cities keep changing after the plan is adopted. The model absorbs road closures, new destinations, and shifting demand, so the next service change starts from today's network.
Point Flow at the GTFS you already publish and the full network loads onto real street geometry. Add APC or farebox counts and the demand model calibrates to them; without those, it estimates demand from land use and journey-to-work data.
A trained optimizer searches route and frequency combinations against your demand data and returns complete candidate networks, weighted between passenger time and operating cost at the ratio you choose.
Each scenario is scored against the service currently running, route by route, with both networks drawn on the same map.
Export the approved scenario as GTFS, plus board maps and the service equity tables your Title VI analysis needs.
The possible configurations of a real city's route network are astronomically many, so planning tools have always simplified away inputs to keep the problem workable. Flow was built to consider all of them at once: a deep reinforcement learning model over graph neural networks learns network topology from real and synthetic cities, then infers optimized configurations on large networks in under a second.
Holds the full complexity of the network and optimizes routes and frequencies together, so no input has to be simplified away.
under 1 second inferenceEvery recommendation exports to the planning tools you already run: an optimization layer on top of your existing stack.
Four differences carry most of the value. The full story, including what AI does not decide, is on AI and big data in public transportation.
Today's toolsModels leave variables out to stay tractable.
With FlowTransitFlow models far more of the real network, closer to true simulation.
Today's toolsEach variant is hand-drawn and modeled over days or weeks, limiting how many get explored.
With FlowTransitFlow proposes new networks, computing millions of options in minutes and returning the strongest for review.
Today's toolsRidership impact needs a separate travel-model run.
With FlowTransitEvery change re-scores the whole network as you make it.
Today's toolsReports are assembled by hand after the fact.
With FlowTransitAuto-generated reports explain each change with maps, scorecards, and accessibility analysis.
Routes follow roads a bus can drive, so running times come from real road distance and turns. Headways are set by period, and span of service and branches are edited directly, and running times come from your AVL history rather than from geometry alone. Bus lanes and bike lanes sit on the same canvas, drawn and tested with the routes they serve.
You set the weights between cost, service, coverage, and travel time, and hard limits such as fleet size, line lengths, and stop spacing. Flow searches route and frequency combinations within those bounds and returns complete candidate networks, each one scored the same way, so the strongest options surface even when no one would have drawn them.
One network is held as the master plan, beginning as the service running today. Differences are attributed route by route, so if Route 6 improves only because riders shifted onto a faster parallel line, the report shows the shift alongside the gain.
Ons and offs are reported by stop, and passenger load is tracked along each section of a route against the assigned vehicle's capacity. A frequency change that relieves crowding in one corridor while creating it in the next is visible before the schedule is written.
The model stays live between redesigns. Road closures and new points of interest are absorbed with one click, and Flow watches live data for patterns such as bus bunching and suggests an intervention, so every service change starts from today's network. Forecasts learned from your last year of service estimate how each day is likely to run and keep updating through it, so a morning delay's impact on the afternoon shows up early. Planned events work the same way: a football match or a marathon gets its service plan drawn in advance and rolled back after. The same model also runs forward: load the growth your city expects, new housing, a campus, a rezoned corridor, and shape the network for it before it arrives.
An approved scenario exports as GTFS, so the change reaches trip planners and rider apps without anyone retyping a timetable. Maps, comparison tables, and service equity analysis are generated from that same scenario.
These are four of the most common considerations in a service decision, usually with a different data source behind each one and no single place to see them together. How much weight each carries is a policy choice, and no two agencies set it the same way: a ridership goal and a coverage mandate pull in different directions. Flow calculates them for any network you draw, by the same method every time, so your board sets the weights and the numbers stay comparable.
Modeled door-to-door journey time, including the walk to the stop, the wait, and any transfer along the way.
On-time performance and headway adherence modeled from your AVL history, with the recovery time each route needs to absorb running-time variation.
Vehicles required, revenue hours, and revenue miles, including deadhead and layover, calculated per scenario so the trade against service quality is explicit.
How many destinations residents can reach on a 45-minute door-to-door budget, broken out by neighborhood.
Most redesigns are budget-neutral, so service added in one place comes out of another, and the board will ask which neighborhoods absorbed the loss. Flow reports the change in revenue hours, coverage, and travel time by census block group, and tests it against the disparate impact and disproportionate burden thresholds your board has adopted.
Routes and frequencies follow where your ridership and origin-to-destination data show people travel.
Door-to-door time falls across the network, counting the walk, the wait, and the transfer.
Every network is scored on the trips it serves, showing where public transport wins riders from the car.
Headways and fleet estimates use observed running times, and bunching-prone lines are flagged from historical data.
More residents near frequent service, at the same operating budget.
Each scenario shows who gains or loses access, with exportable reports for committee meetings.
Network redesigns are still commonly run as consultant studies, and between those studies planners work with a GIS layer and a spreadsheet. A study delivers alternatives after months, with the assumptions sealed inside a model the agency cannot open, and each follow-up question from the board means another round under the contract.
With the model in-house, alternatives arrive the same week, the assumptions sit in front of the planner, a board question costs an afternoon, and the analysis belongs to the agency.
Book a walkthrough and bring the route question you're working on.