Most operators who have seriously evaluated a platform switch have run some version of the same calculation: what does the current team and infrastructure cost annually, against what they would pay in CPMS fees.
That comparison has a blind spot. The largest costs of running an in-house CPMS don’t appear in any budget. They don’t show up in the headcount line, the cloud infrastructure invoice, or the compliance spend. They accumulate in the things that didn’t get built, the perspectives that never entered the room, and the distance between where the operation is today and where it could be.
Most in-house platforms were built when commercial alternatives were not yet mature enough to trust with core operations. The original reasoning still holds; what has changed is the calculation, and specifically the costs that never appeared in any budget line. We have worked through platform transitions with some of the largest CPOs in Europe. What operators discover, consistently, is that the comparison they had been running left out the costs that matter most.
The work that is always first in the queue
Running an in-house CPMS means your engineering team carries recurring obligations that no commercial platform absorbs on your behalf. Protocol updates, payment recertifications, regulatory compliance cycles: these land in the backlog as scheduled work, ahead of everything else, because the market and the regulators set the deadline rather than your product team.
Those obligations compound with scale: every new market, every hardware manufacturer added, every jurisdiction with its own compliance calendar extends the surface area. The team’s capacity to maintain it doesn’t grow at the same rate.
What those hours displace is the real cost, not the hours themselves. The work pushed back is the work that would advance the business. The compliance sprint is visible on the board. The roadmap item it displaced is not.
The version of your business that doesn’t exist yet
There is a version of your operation that could exist by now if the maintenance queue hadn’t come first. Features on the roadmap for eighteen months. A commercial capability deferred to the next cycle, then the next. Customer tooling your team has the expertise to build, but not the available capacity to begin.
These don’t appear in any audit because they never existed. You can review everything that was built. There is no review for what wasn’t.
Some of what was deferred is now a standard capability among the operators you compete with. Some of it is becoming a commercial expectation in the markets where you operate. The deferred roadmap creates no visible cost line anywhere; its effects show up as the capabilities you don’t have when a commercial opportunity requires them.
Map where your operation stands with the In-House CPMS Benchmark.
The calibration you can only get from outside
In-house teams develop genuine expertise in their own operation. Over time, that expertise comes with an effect that is harder to see from inside: a calibration drift. Without external reference points, the team’s sense of what is hard, what is normal, and what is genuinely unique to their network skews inward, producing a persistent overestimate of how proprietary the requirements are. Custom billing logic that feels irreplaceable. Hardware edge cases that appear uniquely complex. Workflow requirements that seem too specific for any standard platform to accommodate.
Operators who have made the transition consistently describe the same recognition afterwards: most of what felt like irreplaceable proprietary complexity was the standard complexity of running a large network. Firmware management across a dozen hardware manufacturers, multi-tier billing logic for B2B fleet contracts, custom roaming credential structures: these turn out to be challenges that dozens of other operators on the same platform have already worked through. The solutions existed. They were just invisible from inside.
Operators running on a commercial platform across 200+ networks develop a calibration that is structurally unavailable inside a single operation: what peer networks have already solved, what capabilities are becoming market requirements before they appear in a tender document, where the industry is heading before it arrives. A single operation, however well-run, cannot accumulate it.
The knowledge concentrated in too few people
Every in-house CPMS has a small group of engineers who carry the real institutional memory of the system, concentrated by tenure and circumstance rather than by design. They know why a billing rule is hardcoded. They know what the 2021 firmware patch changed and what it left unresolved. They know which hardware edge case requires a workaround that was never formally documented.
The codebase they maintain has also accumulated years of decisions made under operational pressure: choices that made sense in the moment, whose combined effect is that every future change carries slightly more overhead than it should. McKinsey estimates technical debt represents 20–40% of an entire technology estate’s value, a compounding overhead that rarely appears on any single line before it becomes a constraint.
Any large codebase built over years under operational pressure develops this kind of invisible load naturally. The fragility it produces is a business continuity exposure, not just a technical concern. When those engineers leave (through attrition, better opportunities, or the accumulated fatigue of years in maintenance mode), the knowledge does not migrate cleanly. The knowledge gap typically surfaces when the operation is least able to absorb it: during a migration, an acquisition, or a compliance sprint that nobody budgeted for.
If this pattern sounds familiar, the PoC conversation starts with your current architecture.
The gap that does not stay flat
The costs above each carry their own weight. Their combined effect is something different.
Because AMPECO is maintained as a single platform across all 200+ operators simultaneously, every capability shipped goes to all of them at once: capabilities like AI-assisted fault diagnosis, dynamic tariff management, and energy management integrations that are becoming standard requirements in your customers’ markets. For an in-house operator, each of these enters the backlog as something to evaluate, scope, prioritise, and eventually build, alone, from a team already committed to catch-up work.
In the first year, this is a feature or two. By year three, the gap is material: a set of capabilities your competitors have access to that your team has not yet reached on the backlog. By year five, it is a question about what your business can offer and what it cannot: which commercial models you can support, which market requirements you can meet, what your engineering team is available to build when customers and competitors are both moving faster than your backlog allows.
The catch-up overhead, the deferred roadmap, the absence of cross-network calibration, the compounding technical debt: these do not sum neatly. They interact and compound: catch-up overhead consumes the capacity that would clear the backlog; the deferred backlog prevents the roadmap work that would reduce the overhead. The gap between an in-house operation and one running on a commercial platform designed to absorb these costs centrally does not stay flat over time.
What operators find when they’ve been on both sides
The operators who have made this transition with AMPECO did not encounter these costs as theory. They recognised them after the fact: in the capabilities they hadn’t known existed, the problems they hadn’t known others had already solved, the roadmap that started moving within months of switching because the maintenance queue had finally cleared.
The recognition takes the same form: they hadn’t known what was possible because no one inside a single operation can see the full picture of what similar operations have already solved.
Before arriving at those conclusions, there are questions worth asking internally:
- What percentage of your engineering capacity went to protocol updates, compliance work, or payment recertifications in the last twelve months?
- How many roadmap items have been deferred more than twice?
- If the engineers who know the platform best left tomorrow, how long before operations were affected?
- What commercial capabilities have you not built in the last two years that competitors on commercial platforms now offer?
That recognition can come before the gap compounds, or after. The gap between those two moments is material: not because of urgency, but because the engineering team still has the capacity to lead the transition rather than absorb it.
Continue reading:
The Case for Building Your Own CPMS Has Expired — the strategic framing for why the calculation has changed, written for the C-suite and board.
Always Catching Up: Why In-House CPMS Engineering Teams Can’t Build Ahead — the structural reason behind the maintenance overhead: why adding headcount does not solve it, and what shifts when the obligation queue moves to the platform.
