A product expansion gets much more interesting when the engineering work does not expand with it.
First Orion and Vodafone launched branded calling in Ireland today, after earlier Vodafone deployments in the United Kingdom and Germany. The useful detail sits below the market announcement: First Orion says Ireland uses the same CAMARA-based API integration already built into its platform, with no additional integration or development work required on First Orion’s side.
I’d put that beside revenue from the new market: integration work per market added.
Count the second integration
Platform teams spend plenty of time celebrating the first successful integration, but the second one tells you whether you built a reusable boundary or merely survived a project. That second deployment is the receipt.
First Orion has been explicit about the problem. Its Global Exchange was designed around carrier fragmentation, where branded calling across countries historically meant separate technical work with different network operators, different interfaces, and another round of testing. The company added CAMARA-standard API support this year while retaining proprietary carrier integrations for networks that haven’t adopted the standard.
Ireland is a useful test of the abstraction, because the same Vodafone integration now supports another country without a fresh development project on First Orion’s side.
I’ve built products around APIs and external systems, and this is where integration strategy becomes product strategy rather than plumbing. The HTTP request is usually the cheap part. Identity, field semantics, error behavior, certification, rollout coordination, support ownership, and somebody else’s release calendar accumulate around it until the ‘simple integration’ has a project plan.
A standard earns its keep when those differences stop leaking upward into the product.
Reuse needs its own economics
There is a tempting mistake here: declare the interface standardized and assume expansion is now free.
It isn’t, because Ireland still has commercial work, customer onboarding, carrier operations, local support, and whatever country-specific rules sit outside the API. A reusable technical integration removes one class of cost; it doesn’t erase the market.
That distinction makes the metric useful. I’d track engineering days for each additional market, exceptions added to the shared interface, and country-specific code that survives six months after launch. If market three requires another pile of if country == branches, the platform is becoming geography-shaped even though the endpoint names look tidy.
This connects to my earlier argument that API deprecation is really a customer migration problem, because both cases expose the same awkward truth: an API contract includes work performed by organizations you don’t control. Expansion flips the direction.
A good shared contract should make the next deployment less special than the last one, without pretending that commercial or regulatory differences disappeared.
First Orion’s Ireland launch gives that idea a concrete checkpoint. One integration now spans three Vodafone markets, according to the companies, and Ireland required no additional integration development from First Orion.
Ask for the next-market receipt. Reuse is more convincing when the second country arrives without a second engineering project.
Comments
Comments are powered by GitHub Discussions through Giscus.