What the Toll Management Project Taught Us About Betting a Product on an API That Doesn't Exist

The brief arrived with a product concept that made sense on paper. A platform to manage toll payments across multiple operators, taking the friction out of a process that was genuinely broken. Drivers were missing invoices, losing track of charges across different networks, and paying more than they needed to because nobody had built a unified layer across the fragmented toll landscape. The opportunity was real. The problem was that one of the core technical assumptions sitting underneath the whole product had never been validated.

The core technical assumption sitting underneath the whole product had never been validated.

The assumption was that toll operators had APIs. That integrating with them was a matter of development time and negotiation, not a question of whether the infrastructure existed at all. We found out during discovery that it did not, at least not in any form that made direct integration workable. What followed was a period of client education, strategic repositioning, and finding a path to launch that did not depend on cooperation from incumbents who had no particular reason to give it.

This is the account of that project, what we found, how we resolved it, and what it changed about how we approach third-party dependencies from day one.

The Assumption Built Into the Brief

The client came to us with a clear vision and a working commercial model. They understood the user pain well: toll charges scattered across providers, paper invoices arriving weeks late, no single place to see what you owed or had paid. Their plan was to build a platform that sat across the top of existing toll networks and gave users a unified view, with a single payment method connected to all of it.

The commercial logic depended on integration. The product only made sense if it could communicate in real time with toll operators, pulling charge data as it was incurred and handling payments on the user's behalf. That meant APIs. The brief assumed they existed, that they were accessible, and that getting access to them was a matter of making the right introductions and doing the integration work. None of that had been confirmed before we were brought in.

This is a pattern we see at the start of many product briefs involving established infrastructure industries. The founder has a clear picture of the user problem and a plausible model for solving it. The question of how the technical layer will actually work sits one level down, and it tends to stay there until someone goes and checks. On this project, nobody had gone and checked.

What Discovery Actually Found

When we started looking at the technical landscape, what we found was not a coherent API ecosystem waiting to be plugged into. Each toll operator ran its own system, built to its own spec, with its own rules. Some accepted cash, some card only. Charges varied by vehicle type, by axle count, by time of day, by road. The variation was not a detail; it was the whole texture of the industry.

More significantly, there was no consistent API standard across providers. Some had no external-facing API at all. Others had documentation that was either outdated or effectively inaccessible to a new entrant with no existing commercial relationship. The idea that a new product could walk in and start pulling live toll data through clean integrations was not supported by what the infrastructure actually looked like.

Deloitte's research into the US tolling landscape found that across the top 40 toll authorities by revenue, over $20 billion remains owed each year, with $2.24 billion never collected, partly due to paper-based invoicing and broken account conversion processes. That fragmentation is not incidental; it reflects an industry where operators have not been under pressure to modernise their external-facing systems. Deloitte, "Evolving Tolling Landscape".

Why Direct Integration Was Not Viable

Setting aside the inconsistency across operators, the more fundamental problem was commercial, not technical. Toll operators are established incumbents. They have no inherent reason to open their systems to a new platform with no users, no track record, and no leverage. API access, where it exists at all in this kind of industry, tends to come through formal data-sharing agreements that take months to negotiate and generally require the requesting party to demonstrate something worth integrating with.

A brand-new product cannot demonstrate that. The conversations we would have needed to have with toll operators to establish real-time data access would have required us to present a live platform with a user base, which was exactly what we were trying to build. The dependency was circular, and there was no clean way through it.

Building around that dependency without acknowledging it would have been the wrong move. We have seen on other projects what happens when an integration assumption goes untested until late in development. On a production management product for the motion picture industry, we expected to integrate directly with platforms used for storing production documents, and when we finally gained access to those systems, we found they were far more locked down than anticipated. We had to pivot entirely, ingesting emails tied to specific production roles rather than pulling data through a direct connection. The earlier you find this kind of constraint, the more options you have.

Before scoping any product that depends on third-party data, confirm that the API actually exists, that it is accessible to new entrants, and that the commercial terms for access are realistic for your stage. Do not assume infrastructure you have not seen.

Educating the Client on APIs and Industry Relationships

The client understood their industry well. They understood the user problem and the commercial opportunity. What they had not worked through was the technical reality of how a platform like theirs would actually connect to toll operators. Our job at this point shifted from discovery into education, and we needed to do that without making the client feel that the product was impossible, because it was not.

We explained what an API actually is in practical terms: a defined channel through which two systems can exchange data under agreed rules. We explained that having an API available is not the same as having access to it, and that access in regulated or established industries is typically gatekept behind commercial agreements. According to Salesforce's Connectivity Report 2023, 99% of organisations report using APIs to integrate applications and data, which gives the impression that APIs are everywhere and accessible. The harder truth is that access to any specific API depends entirely on what the owner of that system has chosen to expose and to whom.

We made the case that a new product with no users would struggle to negotiate data-sharing terms with operators who had every reason to wait and see. As Simon described it at the time, the smarter path was to release the initial version under a different technical model and then look to establish API integrations later, once the platform had built credibility. The client accepted this framing, which opened up the space to design an alternative approach.

The Preloaded Credit Model: Launching Without Operator Cooperation

The solution we landed on eliminated the real-time integration problem entirely by removing the dependency on it. Rather than trying to pull live charge data from toll operators, we set up corporate accounts directly with each provider. Customer vehicle registration plates were added to those corporate accounts. Users preloaded credit onto the platform, and charges were deducted after the fact as toll events were processed through the accounts we held.

In Simon's words at the time: "we decided to have almost like a client account with all of these services and then the car registrations were added to the actual platform's account and then funds were deducted after the fact." The architecture was not what anyone had imagined at the start of the project, but it was buildable, and it worked.

The model had real advantages beyond simply being achievable. It gave the platform genuine control over the payment flow, because all the funds moved through accounts we administered. It meant the user experience could be designed without depending on operator behaviour. And it meant the product could go live on a realistic timeline without waiting for commercial negotiations that had no guaranteed outcome.

If real-time API access to a third party is not achievable at launch, look for a model that achieves the same user outcome through a different technical route. Preloaded credit, batch reconciliation, and intermediary accounts are all valid patterns that avoid the dependency without compromising the core proposition.

Repositioning the Proposition Around What Was Buildable

The preloaded credit model required a reframe of the product proposition, at least internally. The original vision had been a live integration layer that reflected toll charges as they happened. What we built instead was a managed account structure where the platform handled all the operator relationships on the user's behalf. The user experience was still unified, still simple, still better than what existed before. The architecture underneath was just different.

Repositioning what was buildable also meant being honest with the client about what the product was and was not, at this stage. It was not a real-time integration. It was a managed credit system that abstracted all the operator complexity away from the user. That is still a valuable product. The user does not need to know how the charges are processed; they need to know they are handled. The platform delivered that.

This kind of repositioning requires a degree of trust between the product team and the client. The client had come in with one picture of how the technology would work. We were asking them to accept a different one, while maintaining confidence that the product was still worth building. The educational groundwork from the earlier conversations helped here: because the client understood why direct integration was not viable, they were better placed to evaluate the alternative on its own terms.

Opening Conversations With Industry Bodies

While we scoped and built the preloaded credit model, we were also thinking ahead. The goal was never to leave the platform running on a workaround indefinitely. The preloaded credit structure was the right answer for launch, but a product with genuine scale and commercial ambition would eventually want real data integrations. That meant starting the conversations that would make those integrations possible, even if they could not deliver anything in the short term.

We recommended that the client begin opening dialogue with industry bodies and toll operator groups, not to negotiate API access immediately, but to establish a presence and start building the relationships that commercial agreements require. A product that arrives at these conversations with a live user base and a working platform is in a categorically different position from one that arrives with a prototype and a pitch deck.

This is a version of a pattern we have used in other contexts. On a trading platform for the drinks industry, we inherited a tightly coupled product with no API layer exposed, and getting responses from the third-party developer who built it became a significant blocker. Rather than continuing to wait, we wrote the API specification ourselves, worked to that spec, and had the third-party developer implement it. Taking ownership of the specification broke the deadlock. The same logic applies here: define what you want the relationship to look like, present it clearly, and give the other party a concrete thing to respond to.

The Staged Roadmap: Credibility First, Integration Later

The roadmap we presented to the client structured the product's development in two clear phases. The first phase was about building a working product and establishing credibility with real users. The preloaded credit model was the foundation of this phase. It was the thing that made launch possible, and it was the thing that would generate the track record the platform needed to approach operators from a position of strength.

The second phase was about pursuing direct integrations as commercial relationships became achievable. Once the platform had users and transaction volume, the conversations with toll operators would be different conversations. The platform could demonstrate what it was and what it was doing. That changes the dynamic considerably.

The staged structure also protected the client from the risk of staking everything on a negotiation that might not succeed. If the Phase 2 conversations took longer than expected, the product was still running and growing. The business did not stop while the API relationships matured.

What This Taught Us About Validating Third-Party Dependencies

The toll management project sharpened how we approach any product that relies on third-party data or services. The pattern that caused the problem here, an untested assumption about infrastructure that did not exist in the expected form, is genuinely common. Projects that skip early dependency validation tend to find the problem much later, when the cost of pivoting is significantly higher.

The questions we now ask early are straightforward. Does the API exist? Can a new product access it, or does access require a commercial relationship? What does that relationship take to establish, and how long does it typically take? What happens to the product if access is delayed or refused? These are not difficult questions, but they need to be asked before scoping begins, not after development has started.

We have seen versions of this play out across several projects. On a buying and selling platform for bottled goods, we had already started building the mobile product when we discovered we could not implement the planned API layer. The client's existing web application had been built by another developer in a way that made it too complex to expose cleanly via an API. We ended up embedding web elements from the existing site directly into the mobile product instead.

That added approximately 20% uplift in work across the entire length of the project, and because the client wanted to keep the budget the same, features had to be dropped towards the end. Finding the constraint during scoping rather than mid-build would have changed the shape of the project entirely.

Map every external dependency before scoping starts. For each one, confirm whether access is open or negotiated, what the onboarding timeline looks like, and what a realistic fallback is if access does not come through. Build the fallback into the plan from the beginning.

Conclusion

The toll management project is a clean illustration of what happens when a product concept is built on an infrastructure assumption that turns out to be wrong. The product concept was sound. The user problem was real. The technical foundation the brief assumed did not exist in the form the brief required. Discovery found that, which is exactly what discovery is for.

What we built instead, the preloaded credit model with corporate accounts held across each operator, was the right answer for that stage of the product. It was achievable, it served the user well, and it gave the platform a foundation from which to pursue real integrations once it had the credibility to negotiate for them. The staged roadmap converted a constraint into a sequence rather than a dead end.

The broader lesson is about where validation sits in the product development process. Third-party dependencies need to be tested before they are assumed. The question of whether an integration is possible, and on what terms, belongs in the earliest conversations, not in a sprint review six months into development. Finding the gap early is what gives you the room to design around it.

If you are building a product that depends on external data, third-party services, or incumbent infrastructure, and you want to pressure-test those assumptions before they become expensive surprises, let's talk about your product's technical dependencies.

Frequently Asked Questions