Best Practices: Why transit can't buy tomorrow's software
Transit agencies aren’t failing to innovate. They’re failing to procure innovation.
Across North America, transit leaders are under constant pressure to modernize: improve reliability, enhance safety, reduce operating costs and deliver better rider information—all while managing aging fleets, constrained budgets and intense public scrutiny.
The technology to meet these demands already exists. Artificial intelligence (AI), cloud-based analytics and real-time software platforms are transforming transportation systems around the world. These tools are mature, commercially deployed and deliver measurable results at scale.
Yet in U.S. transit, many of these same technologies struggle to move beyond isolated deployments. Not because they don’t work—but because our procurement frameworks were built for hardware-heavy capital projects, not adaptive, subscription-based software systems.
Nowhere is this mismatch more visible than in how the industry misuses the idea of the proof of concept.
The proof-of-concept fallacy
One of the more abused terms in our industry is the proof of concept. So, let's clear something up: just because your agency has never tested a market-available product doesn't make it a proof of concept.
When AI-powered predictive maintenance is already operating successfully at dozens of agencies, deployed commercially in freight rail and other industries and supported by peer-reviewed research, the next agency doesn't need a pilot. It needs procurement.
Similarly, when real-time passenger information systems using machine learning are serving millions of riders across Europe, the concept is proven. Testing it on your bus line isn't innovation, it's evaluation before purchasing. That's what demos are for.
True innovation happens the first time something is attempted anywhere. After that? It's just new to you.
Yet our industry has a nasty habit of treating every proven technology like experimental research. We run endless proof of concepts on commercially available products. We pilot solutions that have been in revenue service for years. We celebrate innovation grants for technology you can buy off the shelf.
This isn't innovation. It's innovation theater, and there's a reason it never scales.
The guidance vacuum
In the absence of clear federal guidance, agencies default to pilots not out of ignorance, but out of risk management because doing nothing is often safer than doing something new.
I searched the Federal Transit Administration’s (FTA) procurement library for guidance on buying Software-as-a-Service (SaaS) or AI systems for transit. Here's what agencies get: silence.
FTA Circular 4220.1G, the FTA's comprehensive third-party contracting guidance, offers no meaningful guidance on SaaS or AI procurement models. The American Public Transportation Association (APTA) similarly has published studies on AI applications in transit but offers no procurement framework for actually buying them. The FTA's Best Practices Procurement Manual, which dates back to 2016, assumes software still comes in shrink-wrapped boxes with perpetual licenses.
So agencies default to what they know: pilot programs. Test for 18 months. Write a glowing report. Present at conferences. Then struggle to write requests for proposals (RFPs) that enable competition while capturing lessons learned.
The SaaS paradox
Try explaining subscription-based AI software to procurement rules designed to purchase vehicles or physical infrastructure. Transit agencies face impossible contradictions:
-
Budget categories don't exist: Is SaaS capital or operating? Federal grants fund capital. Modern technology operates as a service. The budget line doesn't exist.
-
Acceptance testing breaks down: Traditional procurement demands fixed performance at delivery. AI learns. It starts at one accuracy and improves over six months. Do you reject it at acceptance? Specify the learning curve? Your RFP template has no checkbox for "gets smarter over time."
-
The ownership trap: Traditional procurement demands source code for security. However, agencies rarely have capacity to audit complex AI systems while leading SaaS providers maintain dedicated security teams serving hundreds of clients. Procurement templates written for physical assets struggle to address cloud-native security models.
The hardware stranglehold
Here's a problem few are talking about: Most transit SaaS vendors can't actually sell just software.
They're forced to sell low-end hardware as a means to an end—routers, onboard computers, GPUs, cameras and destination signs—just to get the data needed to make their software viable. Why? Because transit lacks open, standardized hardware platforms that allow software to truly compete.
Europe began addressing this over a decade ago.
The ITxPT model
Information Technology for Public Transport (ITxPT) established hardware and software interoperability standards across European transit. The framework defines three levels:
-
Hardware level: Standardized installation rules, connectors, space requirements
-
Communication protocol level: IP-based interfaces enabling plug-and-play
-
Service level: Data formats and service specifications
The result? Helsinki, Paris, Stockholm and Dubai order buses with ITxPT-certified on-board computers. Any vendor's software runs on standardized hardware. Agencies select the best software without vendor lock-in. SaaS vendors compete on performance, not on who can bundle the cheapest router.
North America is finally catching up. A handful of progressive agencies and business partners are bringing ITxPT to U.S. transit. But we're a generation behind.
What mobility data is building
MobilityData and the Mobility Data Interoperability Principles coalition are making progress on data standards, specifically: GTFS, Transit Operational Data Standard and GTFS-Flex. These enable software systems to exchange information.
But data interoperability alone doesn't solve the hardware problem. We need physical interoperability, standardized on-board platforms (computers, routers, displays, sensors) that create a true marketplace for software.
Without this, innovation pilots become an endless loop. Test the technology; prove it works; then procure low-grade or proprietary hardware that locks you into one vendor's ecosystem. Or start the loop over with a different vendor's incompatible stack.
Innovation theater kills scale
We've run the pilot. Proven the concept—again. Documented the savings—again. Presented at conferences—again. Then...nothing.
The successful pilot uses vendor A's proprietary hardware running vendor A's software. To scale system-wide, procurement issues an RFP. The RFP specifies requirements that accidentally (or deliberately) describe vendor A's exact product. Or it demands “approved equal,” a theoretical pathway to competition that, in practice, traps vendors in endless validation exercises with little chance of true equivalence.
Either way, meaningful competition dies. Innovation stays quarantined.
PRIME creates the procurement space
Procurement Reform for Investment Modernization and Efficiency (PRIME) is a proposed framework that would address some of these systemic barriers by establishing federal match incentives for agencies that:
-
Prioritize outcomes over specifications: Instead of calling out a specific product, agencies specify a need: provide real-time security monitoring with 95% threat detection accuracy. SaaS vendors compete on results.
-
Evaluate lifecycle costs through contractual commitments: Vendors bid total cost of ownership, including all subscription fees, upgrades and support over the contract term, with financial penalties for cost overruns. A guaranteed $500,000 over 10 years beats an upfront $400,000 purchase that balloons to $1.1 million with unforeseen maintenance costs.
With a potential increased federal match as an incentive, PRIME gives agencies financial reason to write RFPs that say solve this problem rather than buy this product.
But PRIME needs industry support to advance through Congress, and even if enacted, it's not a silver bullet. It's one suggested improvement to a fundamentally broken procurement process.
Financial incentives alone won't fix the systemic issues if agencies lack the technical capacity, the industry standards and the regulatory guidance to implement outcome-based procurement effectively.
The interoperability mandate
Policy alone isn't enough. Transit needs parallel work on physical interoperability standards, North America's equivalent of ITxPT.
Agencies should demand standardized on-board computing platforms, open-architecture routers with ITxPT-style specifications and vendor-neutral hardware that allows software competition. Procurement language requiring interoperability, such as MobilityData's Interoperability Principles template RFP language, should become standard practice.
FTA and APTA must provide procurement guidance specifically for SaaS and AI, technical specifications for standardized on-board hardware, best practices for outcome-based software procurement and example RFP language for subscription-based services.
The path forward
We can't procure tomorrow's technology with yesterday's rules or with yesterday's definition of innovation.
Testing proven technology at your agency isn't a pilot program. Buying commercially-available software alone isn't innovative. Treating every procurement like experimental research, then writing RFPs that specify the "winning" experiment guarantees the pilot never scales beyond the vendor who ran it.
Europe's transit systems aren't running innovation pilots. They're running revenue service with interoperable platforms and competitive software markets.
It's time North American transit caught up.
Support PRIME's proposed outcome-based framework. Demand hardware interoperability standards. Stop calling proven technology proof of concept. Write procurement guidance for the software world we live in, not the one we left in 1985.
No single reform will fix this. But combining outcome-based procurement incentives, physical interoperability standards and modern regulatory guidance creates the foundation for actual change.
The technology works. The procurement doesn't.
About the Author
Gabriel J. Lopez-Bernal
President of Icomera North America
Gabriel J. Lopez-Bernal serves as president of Icomera North America, where he leads the company's connectivity solutions for transit operators across the U.S. and Canada. With nearly two decades of experience in transportation engineering and wireless communications for mobile environments, he has established himself as a leading voice in transit technology and procurement reform.
Lopez-Bernal works directly with Congress on federal transportation policy and procurement modernization initiatives, advocating for outcome-based procurement frameworks and lifecycle cost analysis to enable transit agencies to deploy modern technologies like artificial intelligence, Software-as-a-Service platforms and advanced connectivity solutions that current procurement rules often prohibit. He also serves as treasurer on the executive board of the Commuter Rail Coalition.
His work bridges the technical realities of deploying infrastructure with the policy frameworks that govern public investment, positioning him as both a practitioner solving real-world connectivity challenges and a thought leader working to reform the systems that shape transit modernization across North America.