Executive Summary

For most of the last decade, EV charging management software came in two forms: rent a hosted platform, or build your own. That looked like a choice. For the majority of charge point operators it was not one, because the second door had a price of admission almost nobody could pay. A bespoke platform program has historically started in the mid six figures and taken twelve to twenty-four months to reach first revenue, before a single person was hired to keep it running.

So operators rented. Not because renting was a compromise they accepted with regret, but because it was the correct decision available to them. Hosted platforms are inexpensive month to month, quick to deploy, and competent. The trade was never framed as a trade at all. It simply looked like the way charging software was bought.

What that decision cost them shows up somewhere other than the invoice. It shows up in whose roadmap decides which features exist, in what happens to a network when a vendor changes strategy, and in what an operator holds at the end of the term. Those costs were tolerable when the alternative was a seven-figure program. They are harder to justify now that it is not.

Two things changed. The protocol layer beneath every charging platform became standardized enough to productize, and licensing began to scale with the size of the network instead of presenting one enterprise-sized figure to everyone. Together they moved ownership from something only a major could contemplate to something a mid-size operator can put on a shortlist.

Where EV Charging Management Software Becomes a Cost Structure

Every vendor evaluation opens with the same list. Remote start and stop, tariff management, RFID and app authentication, roaming, reporting, firmware distribution, load balancing, payment reconciliation. The list is real, and it is also close to identical across the market, because the obligations underneath it are set by protocols and not by product managers. A charge point management system (CPMS) and a charging station management system (CSMS) name the same layer in different vocabularies: the backend that speaks OCPP (Open Charge Point Protocol) to every charger in the ground, holds session and tariff logic, and turns kilowatt-hours into invoices. Those are the functions any charging backend has to cover before it is worth deploying. An eMSP (e-Mobility Service Provider) platform sits on the driver side of that boundary, owning accounts, apps, contracts, and roaming settlement.

Most operators need both layers, and many discover where the boundary falls only when a roaming partner asks which side of it they are on. That is a platform architecture question long before it is a purchasing one.

Layered diagram of a charging platform stack showing charge points connected over OCPP to a CPMS or CSMS on the operator side, the procurement boundary, an eMSP platform on the driver side, and roaming hubs reached over OCPI 2.2.1, with ISO 15118 Plug and Charge spanning all four layers
Where the operator platform ends and the driver platform begins. Most operators need both layers; the boundary is where a roaming partner asks which side you are on.

The feature list stops being useful the moment two vendors both tick every box, which is now the normal outcome of a competitive tender. What separates the options is not the capability set. It is the ownership structure underneath it, and until recently that structure was decided by the size of your balance sheet.

Two Doors, and One of Them Had a Price of Admission

The standard framing of charging platform procurement offers two paths. Rent an off-the-shelf platform and start fast as a tenant, or fund an in-house build and own the result. Presented that way, it reads as a genuine strategic choice between speed and control.

It was not a choice for most of the market. Building a charging platform means delivering the protocol layer before you deliver anything a customer would notice. OCPP connectivity across multi-vendor hardware, session and tariff logic, charge detail records that survive an audit, firmware orchestration, roaming integration, certification, and the security profile work underneath all of it. None of that differentiates an operator commercially. All of it has to exist before the platform can bill a session.

That work has historically put a bespoke program in the mid six figures at minimum, with twelve to twenty-four months to first revenue, and a permanent engineering team behind it afterwards. For a national operator or an energy major, those are ordinary numbers. For an operator running a few hundred sockets, they describe a door that does not open. At the protocol layer the same problem shows up as a build, buy, or accelerate decision about the OCPP backend, and it lands hardest when a utility becomes a charge point operator and inherits both halves at once.

The binary was never really rent-versus-build. It was rent, or be large enough to build.

So Operators Rented, and They Were Right To

Renting was the correct decision, and for many operators it still is.

Hosted platforms are priced per charge point or per connector per month, which makes them cheap to start and predictable to budget. They deploy in weeks. They arrive with protocol compliance already handled, hosting included, patching included, and someone else on call at three in the morning. Against a seven-figure program with a two-year horizon, that is not a close contest. Any operator who chose a hosted platform over a bespoke build was reading the situation accurately.

The service-model variant of the same question, where the operating function itself is outsourced rather than the software, is examined in our comparison of running your own CPO operation against buying it as a service.

Hosted platforms are good products, and the operators running on them did not make a mistake. What has loosened is the constraint that made the decision automatic.

What Renting Actually Costs, and Where the Cost Appears

The monthly fee is the visible price. It is not the interesting one.

Start with how the cost behaves. Platform pricing is indexed to the size of your fleet, while platform value is indexed to something else entirely: utilization, tariff design, roaming reach, and how well you monetize flexibility. Add three hundred slow AC points at a retail site with modest throughput and your platform invoice grows exactly as fast as it would for three hundred high-utilization DC bays. Layer on an annual uplift applied to a base that is itself growing, and the curve has no natural ceiling. It rises with every charger you energize, indefinitely, for as long as you operate the network.

Then consider your position at renewal. In year one you can walk. By year four your session history, tariff configuration, driver accounts, roaming agreements, and charger commissioning records all live inside the platform, and the cost of moving them has grown in proportion to the network you have built. The vendor knows this. So does the operator, usually about six weeks before the renewal date.

There is a continuity dimension as well. Charging platforms are software businesses, and software businesses get acquired, restructured, and occasionally withdrawn from a market. Anyone who has operated in this sector since 2020 can name an example without pausing. When it happens, the hardware in the ground keeps drawing power and the layer that made it a managed network does not, and the operator discovers that their continuity was always a function of somebody else’s strategy. That risk is real, it is difficult to price, and it almost never appears in a total cost calculation.

Dimension Rent (hosted platform) Build (in-house, from zero) Own (licensed core)
Time to first live session Fastest — weeks Slowest — 12 to 24 months Weeks to a few months; the core already exists
Entry cost Low, but tied to a subscription that never ends Very high — team, infrastructure, QA, certification Moderate — you pay for configuration, not for the core
How cost behaves as you grow Climbs with every charger energized, with no ceiling Tracks the team you keep, independent of charger count Tracks a smaller team; no per-charge-point or per-transaction fees
Who decides which features exist The vendor. Your priority competes with every other tenant’s You, limited only by your own capacity You, on a codebase you can modify
Protocol compliance (OCPP, OCPI, ISO 15118) Pre-built, but versions arrive on the vendor’s schedule Built and certified from zero — the largest hidden cost Pre-built and production-proven; budget goes to differentiation
Data ownership Partial — typically in the vendor’s infrastructure, on their terms Full Full — location, retention and access are yours
Cost of leaving High and rising: data, configuration, roaming contracts and driver accounts move together Not applicable — there is nothing to leave Not applicable — the source code is already yours
Operational responsibility Vendor-carried: hosting, patching, upgrades and 24/7 operations bundled in Yours entirely, including protocol migrations and certification upkeep Yours, and shareable through a support or managed-operations arrangement
Exposure to vendor business risk High — a strategy change or withdrawal is your problem None Low — the platform runs whatever happens to the supplier
What you hold at the end of the term A renewal notice and a migration project you have not scoped A codebase and a team that understands it A codebase and a team, reached far sooner

The last dimension is the one operators are least able to quote, and the one that rewards acting early. Cost of leaving is the only number in charging procurement that rises on its own, without anyone deciding to increase it, every time you energize another charge point. Extracting session records, re-commissioning chargers against a new backend, renegotiating roaming agreements, migrating driver accounts: each of those is a manageable piece of work at three hundred charge points and a program at three thousand.

Which makes it a question of timing more than a question of difficulty. The exit is paid once. Paid at today’s network size it is an ordinary migration project, of the kind operators run when they change any core system. Deferred three years, the same move costs multiples of that, and the decision to defer is rarely taken deliberately. It is simply what happens while the network grows. The operators who find this hardest are the ones who waited for it to become urgent.

The Threshold Was the Barrier, Not the Price

Renting carries real long-term costs in roadmap control, data ownership, exit position, and vendor dependency. Operators have generally understood this. They accepted it anyway, because the alternative required capital and a time horizon they did not have.

That is what makes the ownership question different from an ordinary build-versus-buy calculation. Build-versus-buy assumes both options are available and asks which is better. For most of this market only one option was ever available. The apparent consensus in favor of hosted platforms was never the outcome of a fair comparison. It was the outcome of a threshold — and that threshold has moved.

The Third Position: Owning Without Building

Two developments did it.

The first is standardization. When charging platforms could not be productized, a vendor could sell an opinionated hosted product or a services team could build to order, and nothing sensible existed in between. OCPP was fragmenting across vendor dialects, roaming was immature, and every deployment carried enough bespoke integration work that a shrink-wrapped core would have been obsolete before it shipped. Those conditions have gone. The Open Charge Alliance, which stewards the specification, certifies against OCPP 1.6J and 2.0.1 as its two production profiles and published OCPP 2.1 in early 2025 — a sequence that only makes sense once the earlier versions are settled enough in the field to build on. The EVRoaming Foundation’s OCPI 2.2.1 has done the same for the roaming interface, and ISO 15118 has defined the certificate handling behind Plug and Charge. A large majority of any charging platform is now commodity plumbing built to public specifications, and commodity plumbing productizes well.

The second is commercial. A platform core that has been built once and hardened across many deployments does not need to be sold at the price of a bespoke program, because it is not one. Licensing that scales with network size, without per-charge-point or per-transaction fees, prices ownership against what an operator actually runs. That is what removes the enterprise-scale entry condition, and it is the part that matters for anyone who was locked out of the old binary.

Positioning map plotting time to a first live charging session against what an operator holds when the contract term ends, showing rent, build and owning a licensed core, with the owned position occupying the quadrant the rent-or-build binary had no room for
Speed to a live network, plotted against what you hold when the term ends. The owned position sits in the quadrant the rent-or-build binary had no room for.

Codibly’s CPMS Engine and eMSP Engine are built on that model: a one-time license, full source-code ownership, no per-charge-point rent, and no dependency on our release queue once the platform is yours. The operator side covers multi-vendor charger management, tariffs, settlement, and monitoring. The driver side covers accounts, apps, roaming, and billing. Both are cloud-agnostic, because a platform you own that runs only in someone else’s tenancy is only partly owned. You start from a running platform instead of an empty repository, and you own what you start from.

The evidence that an owned core survives contact with production sits in the portfolio. IMP PAN runs a scalable OCPP 1.6J server that Codibly developed for a Horizon 2020 research program spanning Poland, Denmark, and the Netherlands, with vehicle-to-grid energy transfer and multi-site management across three national contexts with different grid and regulatory conditions. On the speed side, an EV-charging hardware manufacturer had a full OCPP 1.6 integration delivered into its cloud platform, with V2G and Plug and Charge support, in one month. Neither of those is a hosted-platform timeline story or a two-year build story.

What Ownership Still Does Not Buy You

The capital threshold has come down. The operational one has not.

A hosted platform bundles hosting, security patching, protocol version upgrades, certification maintenance, incident response, and round-the-clock operations into one predictable fee. Own the core and every one of those responsibilities becomes yours. They do not disappear because the license was affordable. An operator who takes ownership without a plan for running it has bought a liability with a lower entry price, which is worse than renting, not better.

There are three honest answers to that, and they are not the same. Staff it, if you have or can build a platform team. Contract it, through a support or managed-operations arrangement that leaves the code yours while someone else carries the on-call rota. Or decide the capability question dominates and keep renting, which remains entirely legitimate. What has changed is that this is now a capability decision rather than a capital one. Previously the money settled it before capability was ever discussed.

One thing ownership leaves intact, despite a persistent assumption otherwise, is network reach. Plug and Charge and roaming are protocol obligations under ISO 15118 and OCPI, available to any conformant platform. What ownership changes is who schedules the integration work.

Which Position Fits Your Network

The question is no longer which platform is best. It is which constraint binds hardest: capability, speed, control, or integration.

Run the test in this order. First, count the engineers you would actually assign to platform work, not the ones you hope to hire, because that number decides whether ownership is available to you at all. Second, list the three capabilities that would differentiate you commercially, and ask a precise question about each: not when it would ship, but whether it would ever be built. Several hosted vendors now offer release-channel controls that let an operator choose how quickly new features arrive, which is a real answer to timing. It is not an answer to selection. A feature absent from your vendor’s roadmap arrives on no channel, and the capabilities most likely to differentiate you are the ones your competitors on the same platform have not asked for either. Third, price your exit in money and in elapsed months. Fourth, project your charge point count at year five instead of today, and ask which cost curve you would rather be standing on when you get there.

Operator profile Binding constraint Position that usually fits Test to run first
Small network, no engineering function, no plan to build one Capability: nobody to run a platform at 3 a.m. Rent — or own with a managed-operations arrangement attached. Ownership without a plan to run it is a liability with a lower entry price Check the exit clause and the data-export format before signing, not at renewal
Mid-size, growing fast, small platform team Speed: market share is still being taken The position that changed most. Ownership was previously unavailable at this size and is now worth evaluating on its merits Project the charge point count at year five and ask which cost curve you want to be standing on
Large, multi-country, standing engineering function Control: roadmap and tariff logic are competitive assets Own a licensed core. The economics were already working before the threshold moved Price the exit from the incumbent platform in money and in elapsed months
Enterprise entering charging from an adjacent business Integration: loyalty, fuel card, ERP and identity systems already exist Own a licensed core. Bespoke integration is the whole point List the internal systems the platform must join, then ask a hosted vendor for their roadmap dates
Roaming-heavy operator with a driver brand to protect Differentiation: pricing, app experience and loyalty carry the margin Own the driver-side core; rent or own the operator side separately Name the three capabilities that would win drivers, and ask whether your vendor would ever build them

If the exit number is already larger than a year of platform fees, the ownership question has stopped being strategic and become urgent. The same lens applied to the revenue side appears in our analysis of charging business models in saturated markets, where margin turns on control over pricing and flexibility instead of session volume. On the cost side, the equivalent question is control over the roadmap and control over the exit. Where an operator wants capability the standard core does not carry, custom EV software development extends an owned platform without restarting from zero.

What You Hold at the End of the Term

The operators who rented were not wrong. They read the options in front of them and chose correctly. The options have since changed.

Ownership used to be a privilege of scale. It required capital that only majors could commit and a time horizon only they could absorb, which is why the market settled into a pattern that looked like consensus and was really just arithmetic about who could afford what. Standardized protocols made the platform core productizable. Licensing that scales with network size made it purchasable. Between them they turned ownership from a question of how large you are into a question of how you want to operate.

Which is not the same as saying every operator should own one. It is saying the question is now open to operators for whom it was closed, and that it is worth asking before the exit price makes it expensive to ask. If your per-charge-point spend is growing faster than your per-charge-point margin, or the roadmap you need is not the roadmap you are being offered, the CPMS Engine is the place to start the conversation, and the exit-cost number from the test above is the most useful thing to bring to it.