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 prioritizing algorithmic automation for simpler microtransit deployments, or smaller operations where multi-service complexity are not primary requirements.
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 |
| 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 |
| 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 | !Partial — enterprise deployments exist; independently verified benchmarks limited |
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?
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?
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?
- How does the platform handle live traffic conditions during a trip in motion?
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.
Overnight, we effectively eliminated the need for overflow providers. Two-hour booking wait times went to nearly zero, and on-time performance moved past 96%.