The engineers on a well-run in-house CPMS team have a clear view of what the network should build next and often a sprint board that prevents them from getting to it.
The dynamic holds across team sizes and markets, regardless of how carefully sprints are planned or how capable the team is, and the reason is structural. The in-house model assigns every infrastructure obligation to one engineering team for one network: protocol compliance, regulatory requirements, commercial integrations. Each is absorbed in full, every time it arrives. On a commercial platform, the same obligation is handled once and the benefit distributed. That asymmetry, compounding with each infrastructure obligation, is what prevents in-house teams from building ahead, and more headcount does not change it.
The maintenance obligation is always the first claim on capacity
Engineering obligations in EV charging fall into three distinct categories, and an in-house team carries all three for their network alone.
The first is industry standards. Hardware manufacturers certify against OCPP, and current OCPP support is increasingly a qualifying criterion in public procurement across EU markets. Any gap creates operational exposure. When a new version becomes market standard, implementation is not optional.
The second is regulatory requirements, and they are not uniform. AFIR (the EU’s Alternative Fuels Infrastructure Regulation) is pan-European: payment terminal mandates came into force in April 2024 and apply to public charging operators across the EU. Eichrecht is German-specific: legally binding fiscal metering requirements for public charging that do not apply in France or the Netherlands. An operator managing networks across DACH carries a stack of country-level obligations simultaneously, each on its own implementation cycle.
The third is commercial integrations. Payment terminal certifications do not expire once and stay current: they run on manufacturer cycles, require re-certification when hardware or software changes, and vary by market. OCPI connections to roaming hubs require active credential management, version alignment as hubs upgrade, and re-negotiation when roaming agreements change. Each new market the operator enters brings its own payment processor, its own acquiring bank requirements, its own testing environment. The work is not done once. It recurs, on timelines set by third parties.
All three share one characteristic: they are always first in the development queue, because parity is a market condition. An operator cannot compete in public procurement without current OCPP support. It cannot process card payments without valid terminal certifications. Deadlines are externally set. When one arrives, it displaces whatever product work was planned for the same sprint. The queue also expands: each new market adds regulatory scope, each new hardware manufacturer adds firmware edge cases.
The dynamics work differently on a purpose-built, hardware-agnostic platform. When AMPECO implements a protocol update or a payment integration, the work is done once and every operator on the platform benefits. AMPECO serves 200+ charging networks; that single implementation cycle is distributed across all of them. An in-house team absorbs the same work alone, then absorbs it again when the obligation next arrives. Growing the team improves throughput; it does not change the underlying ratio. The ceiling on available development capacity is not total headcount; it is total headcount minus what the obligation queue has already claimed.
The development gap compounds beyond missed features
The most visible effect is a release schedule that slips. Features scoped for Q1 land in Q3, because the engineering cycle absorbing infrastructure obligations cannot simultaneously sustain a fast product cycle. Drawn from the operational problems hundreds of operators have actually encountered, AMPECO ships capabilities that many in-house teams carry as next-quarter ambitions. Automated fault diagnosis, session intelligence across OCPP logs and billing records, AI-assisted analytics: capabilities in-house teams have in roadmap cycles, built on AMPECO because dozens of operators surfaced the need simultaneously.
Product depth is where the gap compounds silently. The platform reflects operational problems that no single-network team would encounter or prioritise on their own. The depth of a proprietary platform is bounded by one team’s remaining capacity after the infrastructure work is done.
The strategic consequence is harder to see, and the one most CTOs underestimate. Every hour spent on OCPP version management, terminal recertification, or firmware edge cases is an hour not spent on what makes this particular charging network different from every other. The question that surfaces for most technical leaders at this stage is the right one: is this network building a charging business, or running a software company? Most in-house operators did not set out to answer the second question.
The model, not the team
The engineers who feel this dynamic most acutely are often the strongest on the team. They can see clearly what the product should become. The distance between what they know needs to be built and what there is capacity to build is a precise measure of the structural constraint, not of the team’s capability.
In-house teams that have tried to break the cycle (protecting innovation time, restructuring sprints, adding engineers) report the same result: the obligation queue expands to fill available capacity, because the deadlines are external and the requirements are real. The pattern holds whether the team is fifteen engineers managing a regional network or eighty managing a national one. The obligation queue scales with the network, not with the team. A larger team absorbs a larger obligation queue.
The frustration most technical leaders describe is not a management failure. It is an accurate reading of the model.
Your engineers aren’t slow. They’re running as fast as they can, just to stand still.
The domain knowledge, institutional understanding of the network, and technical competence those engineers carry are not lost when the infrastructure queue moves to AMPECO. They become available for the work the business actually needed from them.
What the engineering team builds when the queue is handled elsewhere
When the infrastructure queue moves to AMPECO, the differentiated product work moves from the backlog into the sprint: custom commercial logic for fleet agreements and revenue-sharing arrangements, vertical-specific workflows, B2B integrations the business was always capable of delivering. The model, not the team’s capability, was the constraint.
Operators that have made the transition report the same pattern: the product backlog that had been queued behind the infrastructure work starts moving within months. The same team, the same domain knowledge, different work.
The catch-up dynamic is structural. The question worth asking is not how to make the obligation queue move faster; it is what this engineering team builds when AMPECO handles it instead.
Continue reading:
What Are Your In-House CPMS Engineers Actually Building? — the framework for sorting your team’s sprint board into the two columns, and seeing where available capacity is actually going.
The In-House CPMS Costs Nobody Talks About — the costs behind the catch-up dynamic that do not appear in any budget line: the deferred roadmap, the calibration loss, and the gap that does not stay flat.
