Look at your sprint board from last quarter, with completed work still visible. What does that column say?
For most in-house CPMS teams: OCPP 2.0.1 migration. Payment terminal recertification. OCPI credential refresh. ISO 15118-20 compliance sprint. Firmware edge case for a specific hardware manufacturer. Another OCPI credential refresh.
Commodity work — protocol compliance, payment terminal certifications, regulatory update cycles — that every network must do, and that none compete on.
Every item on the list is necessary, thoroughly justified, and the direct result of operating a charging network in 2026 — but none of it is unique to your network. Every operator with a deployed fleet ran an identical sprint at some point in the last twelve months.
The commodity/differentiation question is not about whether this work matters. It is about whether your engineers should be the ones doing it. The framework below sorts your team’s workload into two columns, shows where the constraint lives, and explains what shifts when one column is handled elsewhere.
What every charging network shares — regardless of how it’s built
Commodity capabilities are the infrastructure obligations every EV charging network must maintain — OCPP compliance, payment terminal integration, roaming protocol support — that produce zero competitive advantage when complete. They do not appear in any CPO’s pitch deck as a competitive advantage. They appear on the sprint board as recurring work.
OCPP compliance is the most visible item. Every network runs it, every hardware manufacturer expects it, and every version update from 1.6 to 2.0.1 is a sprint that delivers zero competitive advantage when complete. The engineering hours are real. The outcome is parity, not an advantage. OCPP 2.0.1 is increasingly specified in public procurement tenders across Northern Europe. An operator that has not implemented it cannot compete for those contracts, regardless of team size.
Payment terminal integration follows the same logic. AFIR compliance (April 2024), Adyen, Payter certifications, fiscal requirements across markets including German Eichrecht: mandatory, identical across operators, renewed on regulatory cycles that no network controls. One top-five UK charging operator managed 5,500 payment terminals with four developers and no dedicated product manager. Finance staff manually reconciled thousands of sessions daily because terminal tariff data did not match backend records. That is not a strategic failure; it is what the commodity maintenance model costs at scale.
OCPI roaming protocol maintenance is the same work for every network participating in roaming. Credential exchanges, hub connections, CDR validation: the effort is identical regardless of which system runs underneath.
Regulatory compliance cycles arrive on a schedule no operator sets. ISO 15118-2 Plug and Charge became mandatory for newly installed public AC charging points under AFIR from January 2026 — with ISO 15118-20, the next-generation version, following from January 2027. German Eichrecht, NEVI requirements: each is a dedicated sprint. For most in-house teams, the regulatory queue is not a projection; it is the live state of the backlog.
Firmware version management compounds all of it. One UK network, after 15 years of operation, was managing 111 firmware versions across 12 hardware manufacturers. Every hour spent keeping that current produced no competitive advantage, at any point in those 15 years.
The commodity list is long, and it is exactly the same regardless of whether a network operates 500 charge points or 50,000. The differentiation list is an entirely different matter.
What your network actually competes on
The capabilities that make one charging network genuinely different from another are not software infrastructure. They are the sum of what a specific operator has built, contracted, or earned that no other network can replicate.
Location footprint is the most tangible example. A CPO’s sites, exclusivity agreements with commercial landowners, revenue-sharing arrangements with petrol forecourts and retail groups: none of this lives in the CPMS. It is the physical network, and it is not replicable by any platform.
B2B commercial relationships define how an operator monetises its network. Fleet agreements, workplace charging partnerships, revenue-sharing logic with commercial location partners: these are business model decisions, not platform features. The concern operators raise most often when evaluating a platform switch is not about losing protocol capabilities; it is about whether their custom commercial logic — complex payout structures, revenue-sharing arrangements, B2B pricing rules — can survive the migration intact. It can: this logic sits on top of the infrastructure, not inside it. In practice, that means operator-owned code communicating with the platform through AMPECO’s API layer — custom billing rules, workflow logic, and B2B contract management in operator-controlled repositories, with platform updates absorbed centrally without touching the operator’s codebase.
Vertical-specific workflows are genuinely proprietary and remain so regardless of which infrastructure layer runs underneath. One example: a UK lamppost charging network built a custom OCPI-based portal enabling smart charging without driver registration, a municipality reporting application, and an installer service app — all as operator-owned software sitting on top of AMPECO’s infrastructure layer. That layer handles OCPP, payments, and roaming. The operator’s code handles what makes the business different.
Driver experience and brand are where the operator’s choices are most visible to end users: the white-label app, the subscription model, the session communication when something goes wrong. AMPECO’s platform provides the infrastructure for that experience. The operator defines it.
Commodity infrastructure and proprietary capability are separable. AMPECO’s API surface supports complex, operator-specific use cases. Custom billing logic, vertical workflows, and B2B contract management do not need to live inside the infrastructure layer. They run on top of it.
The commodity/differentiation split is conceptually clean. The more difficult question is what the split actually looks like on your team’s sprint board right now.
Where your engineering team’s capacity is actually going
The exercise is straightforward. Take the last six months of completed engineering work and sort each item into two columns: commodity (every network must do this) or differentiation (only your network does this).
For most in-house CPMS teams, the split is not close. The commodity work covered above is not the exception on the sprint board; it is the majority of it. Networks that have been asked to account for this honestly report 43% of engineering headcount allocated to maintaining platform essentials — across teams of 15 to 90 engineers, the ratio stays consistent.
The structural reason the split stays skewed: commodity obligations expand with every new market entered, every new regulatory cycle, and every hardware manufacturer added to the network. Maintenance mode is not a temporary state for an in-house team. It is the permanent condition of the model.
This creates a specific constraint. The strongest in-house engineering teams are often the most constrained by commodity overhead. A 15-person team managing 5,000 charge points spends the same time on OCPP compliance as a 90-person team managing 30,000. The ceiling on innovation is not headcount. It is the fraction of headcount that commodity work has not claimed.
The redeployment follows the same pattern each time. When engineers stop absorbing the commodity backlog, the queue of actual product work starts moving. Scheduled charging, dynamic pricing integrations, custom B2B portal workflows: capabilities that had sat behind the compliance work for years get built within months of switching to a commercial CPMS. Not because the team grew, but because their available capacity changed.
The In-House CPMS Benchmark maps where your network stands across seven capability dimensions.
What the commercial market can do today that it couldn’t in 2018
AMPECO ships new capabilities every working day, Monday through Thursday, at four times the throughput of its pre-AI development baseline — measured by features shipped per sprint. A feature an in-house team puts on their Q4 roadmap may already be available to 200+ operators on a commercial platform before the sprint begins. The pace is driven by what those operators are actually running into — which means the platform’s roadmap is shaped by the collective operational reality of networks like yours.
When a regulatory standard becomes mandatory, AMPECO implements it once across the platform. An in-house team implements the same standard once, for their own network alone, as a dedicated sprint during which no differentiation work is done. That structure repeats for every regulatory update: one centralised implementation versus one per-network sprint.
In 2018, no EV charging platform offered automated fault diagnosis. Operators managed hardware issues through manual processes, log analysis, or monitoring tools purchased separately. Today, CoOperator — AMPECO’s AI operations agent — provides automatic fault diagnosis on hardware fault or connectivity loss, session intelligence that cross-references OCPP logs, billing records, and charging curves, and full authorisation traces. In-house teams are currently buying separate monitoring tools to approximate what ships as a standard feature on a commercial platform.
For operators evaluating the transition, AMPECO provides dedicated migration support and account management through the onboarding process — the infrastructure complexity doesn’t transfer to the operator’s team.
Justin Meyer, Managing Director of Evolt/SWARCO, ran this evaluation: after 15 years of in-house investment, does the infrastructure case still hold? He chose AMPECO in early 2026. His framing: “AMPECO stood out as the clear partner for us, demonstrating the technical depth and long-term development capability aligned with how our business, our customers’ needs and the wider market are evolving.” Fifteen years of in-house experience is the relevant reference point for that evaluation.
This is not a claim that commercial platforms are superior in every dimension. The sharper question is whether the capabilities your in-house team still manages require owning the infrastructure.
The exercise worth running
The two-column test is a mirror. Operators who run this exercise find the same thing: not because their platforms failed them, but because the category has matured past the point where owning the infrastructure delivers what it once did. The capacity absorbed by commodity work becomes available for the differentiation work that had been queued behind it for years.
That is the redeployment question: what does the engineering team build when the commodity queue stops being permanent?
The In-House CPMS Benchmark maps where your network stands across seven capability dimensions — infrastructure, compliance, commercial capabilities, and the gap between your current state and what best-in-class platforms offer today.
Continue reading:
Always Catching Up: Why In-House CPMS Engineering Teams Can’t Build Ahead — the structural reason the commodity split stays skewed, regardless of team size or how carefully sprints are planned.
Five Things In-House CTOs Get Wrong About Working With AMPECO — if the two-column exercise raises questions about what a platform switch would mean for your custom logic, your team, and your specific setup.
