How to evaluate transit software you will only use a few times a year

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.

Most software evaluation advice assumes a full-time administrator who will become an expert. Small transit does not work that way. The person evaluating is usually the person who will use it, a handful of times a year, alongside four other jobs.

Ask these in the demo

Show me a service change from start to published, without cutting away. Time it. If the salesperson skips steps, those steps are the hard ones.
What happens the day after go-live when the person you trained is out sick?
Show me the export. All of it, in an open format, right now. Not a support ticket — a button.
What is the total for a fleet of our size in year two, including support and any per-vehicle charge?
Who answers the phone at 5:40am when the board is wrong, and are they in our timezone?
What is the smallest agency currently using this, and may we call them?

That last question is the most informative one on the list. A vendor whose smallest live customer runs forty vehicles has not built for you, whatever the brochure says.

Pricing traps worth naming

Pattern	How it is presented	What it does to you
Per-trip pricing	Fair — you pay for what you use	Taxes exactly the ridership growth your funders want, and makes grant budgeting guesswork
Per-seat licensing	Standard industry practice	Discourages giving drivers and volunteers access, so the data goes back onto paper
Setup fee quoted late	Standard implementation	Commonly five to ten thousand dollars, arriving after you have already chosen
Annual minimum by fleet size	Volume-based	Prices out anyone under about ten vehicles by design
Module unbundling	Only pay for what you need	The three modules you need are each extra, and the base is useless alone

Close view of weathered working hands holding a creased paper timetable annotated in pencil, resting on a denim-clad knee. — **Plate 11**Marked up by hand, because the printed version stopped being true in March.

Insist on these in writing

A full data export in an open format, available to you at any time without asking.
The total year-two cost at your fleet size, in dollars, not a range.
What happens to your data if you leave, and how long you have to retrieve it.
Notice period for price increases.
Whether your data is used to train anything, and whether you can decline.

Run a real pilot, not a trial

A free trial where nobody has time to enter real data tells you nothing except that the login page works. A pilot is different: it uses your actual service, and it has a question attached to it that can come back 'no'.

Pick the line or service that changes most often. That is where the software either helps or does not.
Enter it properly — real stops, real times, real crew. Fictional data hides every problem you are trying to find.
Run it in parallel with whatever you use now, through one full service change. Two weeks of quiet operation proves nothing.
Write the question down before you start: 'can somebody other than Dana publish the autumn timetable unaided?' Then answer it honestly.
Ask the vendor for nothing during the pilot. How far you get without help is the finding.

Do the same pilot with two vendors if you can. Comparing two real attempts is far more informative than comparing two demos, and it costs you one extra fortnight.

Who should be in the room

The most common procurement failure at small-agency scale is not choosing the wrong product. It is choosing a good product without the person who will use it, who then quietly keeps using the spreadsheet because the new system never fitted how the work actually happens.

The person who will do the scheduling. Not their manager. Them.
Whoever answers the phone when a rider's trip changes, because they know which promises the system has to keep.
Somebody from maintenance, if equipment availability is going to touch the schedule — and it should.
The person who assembles the board report, who will discover on their own whether the reporting is real.

The quiet test

Have the person who will actually use it — not the person evaluating it — attempt one real task alone, with the vendor watching but silent. Not a guided demo. A real task, in silence. What happens in those ten minutes tells you more than the rest of the procurement combined.

If they get stuck and the vendor's instinct is to take the mouse, you have learned something about how the next two years will go.

Questions

Should we run a formal RFP?

If your procurement rules require one, yes. If they do not, an RFP for a small agency often costs more staff time than it saves, and it selects for vendors who are good at RFPs. A structured pilot with two vendors usually tells you more.

Is open source a real option?

Sometimes, genuinely. There are solid open tools for feed management in particular. The honest constraint is that open source moves the cost from a licence to your staff time, and staff time is the thing you have least of.