Start with requirements, not with a demo
It is an expensive mistake to let a vendor’s demo define your requirements. Every demo is choreographed around what that platform does well, so whoever books first tends to set the criteria for everyone who follows. The buyer’s guide flips the order: the requirements worksheet comes first, filled in before you book a call, so you walk into each conversation already knowing what good looks like for a fleet your size in your vertical.
Then score on evidence rather than memory. A platform decision plays out over weeks, and by the time you compare notes the early demos have blurred together. A weighted scorecard lets the whole buying group rate each option against the same criteria — assignment quality, fare-engine depth, payments and settlements, branding scope, migration support and total cost of ownership — so the final choice is defensible to whoever signs it off.
Do the arithmetic yourself
Vendor savings figures are, at best, someone else’s fleet. That is why the calculators here take your inputs and keep them in your browser: your job volume, your empty running, your controller hours, your current bill. If the output does not survive contact with your own P&L, it should not survive contact with a contract either.
Two numbers are worth establishing before anything else. The first is what empty running actually costs you per month, because that is the baseline any dispatch improvement gets measured against. The second is your current platform bill expressed per active driver, which is usually the only basis on which competing quotes can be compared honestly — per-vehicle, per-trip and flat-fee pricing all behave very differently as a fleet grows, shrinks, or swings with the season.
Treat a switch as a protocol, not an event
Switching platforms is what operators worry about most, so it is treated here as a first-class workstream rather than an afterthought. Getting drivers, vehicles, customers, historical bookings, zones and tariffs out of an incumbent in a re-importable format is a task with its own timeline; so is rebuilding whatever will not transfer cleanly; and so is telling your drivers and account customers before they hear it somewhere else.
The published 14-day protocolruns both systems in parallel, keeps the outgoing contract live as a rollback, and cuts over shift by shift. That is a slower story than “seamless overnight migration”, and it is the honest one. Ask every vendor you talk to what their equivalent is, and be wary of any answer that does not include a rollback.
Check what is actually branded as yours
Branding scope is one of the easiest things for a comparison grid to blur, so it is worth being exact about ours. The passenger app and the web booker are white-label: those carry your name, because they are what your customers touch. The driver app is always TaxiDex-branded. Ask any vendor to state the same boundary in writing, because “fully white-label” on a feature list frequently means something narrower once you reach the app stores.
When the reading runs out
At some point a document stops being the fastest route to an answer. If you want to see a console handle your zones and your tariffs, a demo is a live screen-share with a person rather than a recording, and setup is scoped and quoted on that same call. If you would rather test the thing first, there is a 14-day free trial and the pricing is published.
