Spare vs. RideCo: The Transit Platform Built on Transparency and Control
Evaluating transit technology is one of the most consequential decisions an agency can make. This page is designed to help you compare Spare and RideCo side by side — using publicly available information, verified performance data, and questions worth asking any vendor before you sign.
How we built this comparison
This comparison is based on publicly available information: procurement documents, agency RFP responses, vendor webinars, and verified performance data from live deployments. Where agencies have reported operational challenges directly, those are noted. Spare's capabilities are drawn from its own platform documentation and confirmed deployment outcomes. RideCo's capabilities reflect publicly available materials and agency-reported experiences. We've aimed to represent both platforms accurately — if something is incorrect, contact us.
Best for / summary
Spare is best for
Agencies running paratransit at scale, managing multiple service types or providers, and teams that need dispatcher control, open integrations, and ADA compliance built in.
RideCo best for
Agencies where automation is the primary priority and operations teams are willing to work within the system's constraints. Agencies that need dispatcher override capability, trusted out-of-the-box reporting, or direct fleet accountability typically find gaps.
Comparison table
| Capability | Spare | RideCo |
|---|---|---|
| Dispatcher control | ||
| Trip booking & dispatch | ✓Full booking, scheduling, and dispatch workflows for paratransit and microtransit | ✓Full booking, scheduling, and dispatch workflows for paratransit and microtransit |
| Dispatcher manual overrides | ✓Lock trips, drag-and-drop reassignment, force-match, post-trip edits | Limited: forced-ride and tag-based overrides only; agencies report feeling "locked out of their own manifests" |
| Optimization engine | ✓Continuous, real-time optimization with live traffic integration | Limited: no ability to pause or lock assignments; trips repeatedly reassigned |
| Live traffic in routing | ✓Google Live Traffic feeds the Spare Engine directly. Travel times update about every minute, and manifests and ETAs change with them | ✕Reported to rely on historical traffic averages; live conditions do not change routing decisions |
| Rerouting around collisions and closures | ✓Affected trips are re-sequenced automatically; dispatchers step in for exceptions and can still lock trips or pause optimization | Limited: dispatchers report moving trips and editing manifests by hand when road conditions change |
| Optimization pausing | ✓Dispatchers can pause optimization, lock trips, and preview changes before committing | ✕Optimization cannot be paused; standby trips subject to re-optimization |
| Post-trip editing | ✓Full post-trip edits supported with immutable audit log | ✕Trips must be cancelled and rebooked; revenue reporting discrepancies reported |
| Rider creation during booking | ✓New riders can be added in real time during the booking flow | ✕New riders must be created through Admin portal first; 30 min to several hour delays reported |
| Booking portal service hours | ✓Service hours enforced automatically within the booking flow | ✕No time rules built into the booking portal; manual schedule validation required |
| Capability | Spare | RideCo |
|---|---|---|
| Reporting & compliance | ||
| Standard operational reports | ✓Pre-built library covering trips, OTP, ridership, and driver activity | ✓Pre-built library covering trips, OTP, ridership, and driver activity |
| Self-serve reporting | ✓AI-assisted analytics copilot; custom reports built without code or vendor involvement | ✕Custom reports require submission to RideCo; delays and limited flexibility reported |
| ADA paratransit compliance reporting | ✓NTD-ready reporting, ADA-specific metrics, roll calls, and eligibility tagging | Partial: difficulty accessing ADA-specific metrics like excessive ride time reported |
| Dead-head tracking | ✓Full deadhead mileage tracked automatically | ✕Deadhead mileage must be estimated manually by agency staff |
| Transparent support metrics | ✓Real-time support SLAs published at spare.com/support-status | ✕No public support performance data available |
| Capability | Spare | RideCo |
|---|---|---|
| Fleet & integration | ||
| GTFS / GTFS-RT ingestion | ✓Supports GTFS and GTFS-RT data feeds for fixed-route context | ✓Supports GTFS and GTFS-RT data feeds for fixed-route context |
| Open TNC / overflow integration | ✓Bi-directional integration with multiple TNCs; full mileage, time, and cost data returned | Partial: primarily overflow; bi-directional return and multi-provider support limited |
| Fixed-route integration | ✓GTFS-RT supported; multimodal trip planning across fixed and demand-responsive services | ✕Fixed-route integration not supported |
| Multimodal support | ✓Microtransit, paratransit, and fixed-route managed within a single rider app | ✕Multimodal trip options not supported within the platform |
| TNC pricing visibility | ✓Real-time pricing across all connected fleet providers visible in dispatch | ✕Cross-provider pricing not visible in-app; riders must contact agency directly |
| Unified platform (micro + para) | ✓Single platform, single rider profile, commingled operations across service types | Partial: operations, admin, and booking managed across separate systems |
| Capability | Spare | RideCo |
|---|---|---|
| Technology & AI | ||
| Native iOS and Android apps | ✓Production rider and driver apps on iOS and Android | ✓Production rider and driver apps on iOS and Android |
| AI Voice and AI Chat booking | ✓24/7 AI Voice + Chat — 50+ chat languages, 13+ voice languages. Handles bookings, cancellations, ETA queries | Early stage: AI Voice recently launched with limited deployment references |
| Driver behaviour monitoring | ✓AI-surfaced alerts, live map view, duty time tracking, performance KPIs | Limited: alerts and scorecards in reactive list-based dashboards; no AI-driven prioritization |
| Driver navigation | ✓Google Maps navigation with live traffic and rerouting is built into Spare Driver, alongside the live manifest | Limited: reported use of HERE Maps or an external Google Maps link, so drivers move between apps |
| Dispatcher and driver voice (Push-to-Talk)* | ✓Built into Spare Operations and Spare Driver. Voice, text, quick replies, and priority alerts, with every message recorded, transcribed, and tied to the driver, vehicle, and trip | ✓In-platform VoIP push-to-talk with 1:1 and channel broadcasts, voice and text messages, and an emergency priority channel |
* Push-to-Talk is an optional add-on to Spare Demand Response and Spare Fixed Route. It currently runs on the Android version of Spare Driver.
| Capability | Spare | RideCo |
|---|---|---|
| Pricing & commercial | ||
| Enterprise SaaS pricing model | ✓Multi-year enterprise contracts with software, support, and implementation | ✓Multi-year enterprise contracts with software, support, and implementation |
| Transparent pricing model | ✓Per-vehicle SaaS pricing; no zone-based implementation fees | Partial: per-trip pricing; additional implementation fees reported for new service zones |
| Paratransit scale | ✓One of the largest enterprise paratransit footprints in North America including agencies like MBTA and DART | ✓Enterprise paratransit deployments across multiple North American agencies including RTC Las Vegas and SEPTA |
Evaluation questions
Questions worth asking any transit software vendor — including us.
How much control do dispatchers have over the optimization engine?
Live operations regularly produce moments the optimizer cannot resolve cleanly. The workflows that handle those moments determine whether dispatchers stay in control or end up working around the algorithm.
Questions to ask any vendor:
- Can dispatchers override the algorithm directly — moving riders, changing vehicle assignments, consolidating trips — and lock those changes so they're not reassigned later?
- Can optimization be paused or constrained at the trip, vehicle, zone, or system level?
- Is force-matching a direct action, or does it require tags and administrative setup?
- Can active trips be edited in place, or must they be cancelled and rebooked?
- Can new riders be created inside the booking flow, or only through a separate admin system?
Does live traffic change the route, or only the map?
A collision on the main corridor at 8:15 a.m. does not wait for the next scheduled plan. When live traffic appears as a layer on the dispatcher's screen, someone still has to read it, work out which manifests are affected, and move trips by hand while pickup windows close.
Questions to ask any vendor:
- Does live traffic feed the routing engine, or appear only as a visual layer for dispatchers?
- When a collision or closure slows a corridor, does the system or a dispatcher move the affected trips?
- Do rider, dispatcher, and driver ETAs come from the same traffic-aware calculation?
- Do drivers navigate in the same app that holds their manifest, with live rerouting?
- Can the vendor show measured on-time results from agencies after live traffic was enabled?
How many systems does it take to complete routine workflows?
Dispatcher workflow depends on how many tools are required to complete everyday tasks. Workflows that are manageable in a demo can become harder to scale when service rules, rider types, zones, and exceptions expand.
Questions to ask any vendor:
- Which workflows happen in the operations system, which in the admin system, and which in the booking portal?
- Can the vendor demonstrate rider creation, booking, live dispatch, trip editing, and issue resolution without switching systems?
- How many screens or modules does a dispatcher use during a typical shift?
Is dispatcher-to-driver communication part of the record?
When a driver reports a breakdown over a radio, the conversation exists only in the dispatcher's memory. When a complaint or incident review needs to show who said what and which trip it affected, there is nothing to pull. Drivers also end up switching between a radio, a phone, and the scheduling app mid-run.
Questions to ask any vendor:
- Is voice communication inside the same app as the manifest, or does the driver switch tools?
- Are messages recorded, transcribed, and searchable by driver, vehicle, or trip?
- Can a driver raise a priority alert in one step, and is there a discreet option for safety incidents?
- Can dispatch reach one driver, a group, and the full fleet from the same screen?
- What hardware is needed for hands-free use, and is it priced separately?
Can your team get ADA, NTD, and board reports without filing a ticket?
For agencies that produce board reports, FTA review materials, ADA and NTD compliance documentation, and operational dashboards, the question is where in-platform reporting ends and vendor-supported reporting begins.
Questions to ask any vendor:
- Which reports are included in the standard library at launch, and which target ADA, NTD, board, and FTA use cases?
- Can agency staff create or modify reports in-platform, or does that require vendor involvement?
- When a custom report is needed, what is the process and turnaround time?
- Which ADA-specific metrics are available in standard reports, including excessive ride time?
What does the total cost of ownership look like once you're locked in?
Enterprise transit pricing is typically quote-based, with no published rates. Two patterns surface consistently from procurement documents: zone-based implementation fees billed separately, and pre-proposal data simulations used to justify savings claims that are projections rather than measured outcomes.
Questions to ask any vendor:
- What is the total cost of ownership over the contract term, including all implementation, support, and configuration fees?
- Are service zone additions billed as separate implementation fees, and if so, at what rate?
- Is pricing per-vehicle, per-trip, or per-rider, and how does that scale as ridership grows?
How open and stable is the platform at scale?
Vendors often market "open" platforms while delivering uneven integration outcomes in practice. Multimodal capability, native fixed-route integration, automatic deadhead tracking, and cross-provider TNC pricing all become differentiators at scale.
Questions to ask any vendor:
- Can the vendor demonstrate end-to-end multimodal itinerary visibility in a live deployment — not a roadmap?
- Which fixed-route platforms does the vendor integrate with natively?
- When multiple TNC providers are connected, can riders see cross-provider pricing in the app?
- Is deadhead mileage tracked automatically or estimated manually?
Results from live deployments
The following results are drawn from verified live Spare deployments. Performance data is published in linked case studies and cross-referenced against agency reports.
If you're evaluating transit software and want to see how Spare performs in a live environment, we're happy to show you.
Book a DemoOvernight, we effectively eliminated the need for overflow providers. Two-hour booking wait times went to nearly zero, and on-time performance moved past 96%.