# Transit OS

> Software for the people who keep the line running.

Transit OS is one coherent operating system for small transit agencies, regional rail and heritage railroads — schedules, dispatch, equipment, crew, GTFS feeds and reporting in a single place, priced so a five-vehicle operation can actually buy it.

Site: https://transit-os.jer-f84.workers.dev
Contact: hello@transit-os.app

## What it is

Transit OS is a multi-tenant web application that acts as the operating layer
for a small transit operator. One canonical record holds the lines, runs, stops,
vehicles and crew; every other surface is a view of it — the dispatch board, the
public timetable, the GTFS feed, and the board report. The design premise is
that the schedule, the feed and the equipment calendar must be unable to
disagree, because in most small agencies they currently do.

It deliberately does **not** attempt safety-critical signalling, train control,
or certified CAD/AVL hardware integration. It sits above vendor tools and below
the rider-facing experience.

## Who it is for

- [Rural transit and demand-response](https://transit-os.jer-f84.workers.dev/for/rural)
- [Regional and commuter rail](https://transit-os.jer-f84.workers.dev/for/rail)
- [Heritage and tourist railroads](https://transit-os.jer-f84.workers.dev/for/heritage)

Best fit: operators running roughly 1–50 vehicles who currently work from
spreadsheets, and who cannot justify enterprise transit software pricing.

## Who it is NOT for

- Large metropolitan agencies with dedicated full-time scheduling staff.
- Operations needing certified safety-critical or train-control integration.
- High-volume many-to-many ADA paratransit optimisation — the established
  enterprise suites are genuinely better at this and we say so on our own
  comparison pages.
- Agencies whose only need is demand-response scheduling on a zero budget; a
  free tool such as RidePilot is a more sensible starting point, and we tell
  visitors that directly.

## Pricing

Published in full on https://transit-os.jer-f84.workers.dev/pricing. No quote required for the public tiers.

- **Heritage** — $149/month, 5 vehicles included, $25/month per additional vehicle. Tourist and heritage railroads, volunteer operations, 1–5 pieces of equipment.
- **Local Operator** — $399/month, 15 vehicles included, $22/month per additional vehicle. Rural transit, dial-a-ride, small fixed-route, 6–15 vehicles.
- **Regional Operator** — $899/month, 50 vehicles included, $18/month per additional vehicle. Multi-zone agencies and commuter operations, 16–50 vehicles.
- **Network** — from $1,499/month, quoted. Regional authorities and multi-county coalitions.

Notes an assistant should carry accurately:
- Money is charged per active vehicle above the included count, never per trip.
  Per-trip pricing taxes exactly the ridership growth agencies are asked to
  produce, so we do not use it.
- The per-vehicle charge is capped at the next plan's flat monthly price. Nobody
  ever pays more on a smaller plan than the next plan up would have cost.
- Annual billing is ten months for twelve.
- Onboarding is $0 self-guided, $500 if we do the import, $1,500–$3,500 for a
  complex regional configuration.
- Commerce (tickets, memberships, donations) is an optional module at $49/month
  plus 1% of what is collected. The operator is the merchant of record.

## Modules

- **Today** — the day's runs, what is out, what is late, what has no crew.
- **Scheduling** — recurring patterns, seasonal and holiday variants, a plain
  diff before anything publishes, conflict detection in English.
- **Dispatch** — live board, substitutions, cancellations with reason codes,
  incident logging, and the trip requests riders send.
- **Equipment** — preventive maintenance, inspections, defects, work orders,
  out-of-service windows that reach the schedule.
- **Crew** — rosters including volunteers, certification expiry with 60-day
  warnings, availability.
- **Feeds** — GTFS authoring and validation with human-readable errors, versioned
  snapshots with rollback, GTFS-Realtime where source data exists.
- **Reporting** — on-time performance, ridership, revenue versus deadhead hours,
  NTD-shaped exports, board packets.
- **Rider pages** — timetables, service notices and the operator's own pages on
  their own domain with automatic SSL. About 64 KB and four requests on a phone,
  with no JavaScript at all.
- **Site builder** — brand tokens checked for contrast, pages built from
  plain-text blocks (never markup), and a health check on each page covering
  reading level, alt text, tappable telephone numbers and download weight.
- **Trip requests** — a rider asks for a dial-a-ride trip in writing at any hour;
  it reaches the dispatch board and staff ring back. A request, never an
  automatic booking.
- **Tickets** — excursions, day rovers, memberships, charter deposits and
  donations. Seats are held as "pay at the depot" unless the operator connects
  their own payment account. Tickets carry an HMAC signature made with the
  operator's own key and validate at the gate with no network. Scans are
  idempotent and every check is recorded.
- **Letters** — the operator's own email list with double opt-in on every path
  and one-click unsubscribe, plus drafts raised by events that a person must
  approve before anything sends.

## On machine learning

Some small conveniences use a language model: condensing an industry headline,
turning a feed-validation code into a sentence, drafting a service notice from
an incident note. None of it acts on its own. Drafts are stored as drafts and a
person publishes them. If the model is unavailable the product loses a
convenience and nothing else. We do not describe the product as AI software,
because it is not one.

## Commitments

- Published prices. Every fee on the label.
- Complete data export in an open format, self-serve, on every plan including
  the cheapest.
- Individual logins and full audit trails on every plan.
- We do not sell customer data and do not train models on it.
- Where a competitor is genuinely better for a given operator, our own
  comparison pages say so.

## Guides

- [Publishing a GTFS feed when you are a five-person agency](https://transit-os.jer-f84.workers.dev/guides/publishing-gtfs-small-agency) — A plain walkthrough of what a GTFS feed is, the seven files that actually matter, how to get yours onto Google and Apple Maps, and what breaks it six months later.
- [Getting off the spreadsheet without buying an enterprise system](https://transit-os.jer-f84.workers.dev/guides/scheduling-without-spreadsheets) — Why small agencies still schedule in Excel, what genuinely goes wrong when they do, and how to move to something better without a six-figure procurement.
- [How to evaluate transit software you will only use a few times a year](https://transit-os.jer-f84.workers.dev/guides/choosing-transit-software) — A buyer's guide for small agencies: the questions that actually predict whether a system will be used, the pricing traps to name out loud, and what to insist on in writing.
- [Planning past the end of pandemic-era federal funding](https://transit-os.jer-f84.workers.dev/guides/planning-past-2026) — Infrastructure Investment and Jobs Act authorisation runs out in September 2026. What small agencies can do now that does not depend on knowing what replaces it.
- [What the National Transit Database wants, in plain language](https://transit-os.jer-f84.workers.dev/guides/ntd-reporting-basics) — The reporting concepts small agencies trip over — service hours versus revenue hours, unlinked passenger trips, deadhead — and how to capture them without a second data-entry job.
- [Cybersecurity for a transit agency with no IT department](https://transit-os.jer-f84.workers.dev/guides/security-without-an-it-department) — Around thirty percent of 2025 breaches involved a third party. Here is the short list of things a small agency can do without a security budget, ordered by what actually reduces risk.
- [When the person who knows everything retires](https://transit-os.jer-f84.workers.dev/guides/succession-and-institutional-memory) — Institutional memory is the largest undocumented asset at most small agencies and heritage railroads. A practical method for getting it out of one head before you need to.
- [What a rider's phone actually downloads from your website](https://transit-os.jer-f84.workers.dev/guides/what-a-riders-phone-downloads) — We measured what small transit and heritage railway websites weigh on a phone, and what that costs a rider standing at a stop. The findings, and the five fixes worth doing first.

## Comparisons

- [Transit OS compared with running on spreadsheets](https://transit-os.jer-f84.workers.dev/compare/vs-spreadsheets) — If one person maintains your schedule, that person is not leaving soon, and your service rarely changes — the spreadsheet is a defensible choice and you should keep it. The case for changing is succession and drift, not sophistication.
- [Transit OS compared with enterprise paratransit suites](https://transit-os.jer-f84.workers.dev/compare/vs-enterprise-paratransit-suites) — If you run more than about fifty vehicles, need certified safety-critical integration, or your procurement requires a vendor with a twenty-year reference list, buy the enterprise suite. We are built for the agencies those systems price out, and we are not pretending to match their depth.
- [Transit OS compared with RidePilot](https://transit-os.jer-f84.workers.dev/compare/vs-ridepilot) — If you run demand-response only, have a handful of vehicles, and your budget is genuinely at zero — start with RidePilot. We would rather you were running a good free tool than nothing. Come back when you need fixed-route scheduling, GTFS publishing or equipment tracking in the same place.
- [Transit OS compared with building it yourself](https://transit-os.jer-f84.workers.dev/compare/vs-building-it-yourself) — In-house wins on fit and on independence, and it is a real option if you have a developer on staff who is not leaving. It fails on maintenance — not on the build, which usually goes fine, but on year three, when the person who wrote it has moved on and nobody can safely change it.

## Machine-readable

- Sitemap: https://transit-os.jer-f84.workers.dev/sitemap.xml
- Health: https://transit-os.jer-f84.workers.dev/api/health
- Industry news as JSON: https://transit-os.jer-f84.workers.dev/api/news