EV Charging Management Software: Rent It, Build It, or Own It
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.

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.

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.
Frequently Asked Questions
EV charging management software is the backend platform that operates a charging network. It communicates with every charger over OCPP, authorizes and monitors sessions, applies tariffs, manages firmware and load balancing, handles roaming with other networks, and produces the billing and reporting records the business runs on. Operator-facing platforms are usually called CPMS or CSMS; driver-facing platforms are called eMSP platforms. Most networks of any size run both.
In practice the two acronyms are used interchangeably for the same operator-side platform, and vendors differ on which they prefer. Where a distinction is drawn, CSMS follows the OCPP specification’s own terminology for the system a charger connects to, while CPMS is the commercial term for the wider operator platform that adds tariffs, billing, and business reporting on top. The boundary that matters in a procurement conversation runs between the operator side and the driver-facing eMSP side, not between these two labels.
Renting a hosted platform typically takes eight to twelve weeks from contract to first live session, most of it spent on charger commissioning and tariff configuration. Building one from scratch realiztically takes twelve to twenty-four months to first revenue, plus a hardening period. Configuring a pre-built, licensed platform core sits between the two and lands closer to the hosted timeline, because the protocol layer is already delivered and tested.
Historically, yes. A bespoke platform program started in the mid six figures and ran for a year or more, which put ownership out of reach below enterprise scale. Two things changed that: the protocol layer standardized enough for a platform core to be productized rather than rebuilt each time, and licensing began to scale with network size instead of presenting one enterprise-sized figure to every buyer. The remaining question for a smaller operator is not capital. It is whether the platform will be staffed, contracted out, or left unmaintained.