You are evaluating how to develop your eMSP platform — whether to build from scratch, buy a SaaS product, or assemble something in between. Your business case assumes the platform can follow you across markets, across billing models, and across the next 100,000 drivers. Your engineering instinct treats OCPI as another protocol to implement. Your CFO sees a procurement line item.

All three readings miss the same thing. eMSP software development is an architectural decision disguised as a procurement question, and the decisions that actually bind you (OCPI implementation depth, billing flexibility, driver experience ownership, multi-market scalability) are made at the software layer, not the purchase order. Twelve months in, when a fleet customer asks for per-vehicle reimbursement reports or a regulator asks for live price transparency across 300 CPO endpoints, the platform either bends or breaks. That line was drawn in the architecture, not the contract.

This guide covers how to think about developing an eMSP platform that scales. For a definitional primer on what an eMSP is and how the role sits alongside a CPO, see our What Is an eMSP explainer. Here we start one level deeper — inside the software.

What eMSP Software Must Actually Do

Every production-grade eMSP software stack performs four functional roles. If your candidate platform, whether you are buying, building, or assembling, cannot demonstrate all four against live CPO traffic, you are evaluating a prototype, not a platform.

Four Functional Layers of eMSP Software — Role, Inputs and Outputs, and Scaling Risk
Functional Layer What it actually does Primary inputs and outputs How it fails at scale
OCPI Roaming & CPO Connectivity: Protocol layer Connects the eMSP to every CPO the driver may use. Handles OCPI 2.2.1 across all modules (Locations, Tokens, Tariffs, Sessions, CDRs, Commands, Hub Client Info) plus direct bilateral and roaming-hub channels. In: CPO location data, live tariffs, session events, CDRs, command acknowledgements. Out: Driver authorization, session start/stop commands, settlement-grade billing data. Partial OCPI coverage caps the addressable CPO network. Every non-spec-compliant CPO integration becomes custom glue code that compounds into a parallel protocol layer.
Authentication, Session & Token Management: Identity and access layer Issues driver credentials (RFID, app token, QR), authorizes sessions in real time against enrolled accounts, tracks session lifecycle, and manages the token registry CPOs query via OCPI. In: Driver enrollment data, CPO authorization requests, session start/stop events. Out: Authorization decisions (within session timeout), session state, token lifecycle events. Breaks at velocity — token spoofing, session hijacking, and RFID abuse scale nonlinearly with driver count. Without velocity checks, fraud losses and CPO disputes consume the billing margin.
Billing & Tariff Engine: Commercial layer Applies the eMSP’s pricing rules to each CDR, supports subscription, pay-as-you-go and B2B fleet models simultaneously, keeps driver-facing tariffs synchronized with live CPO data, and feeds billing systems. In: CDRs from CPOs, CPO tariff updates, driver subscription state, fleet contract terms. Out: Driver invoices, fleet reimbursement reports, VAT-compliant data, settlement reconciliation. Breaks at the tariff pipeline — mid-session price changes drift out of sync with driver displays, creating AFIR compliance exposure. Breaks again when a second billing model is added after launch and the architecture only supports one.
Driver Experience: Product layer Driver-facing application and portals — station locator, session control, payment, billing history, and (for fleet operators) per-vehicle reimbursement dashboards. In: Live CPO location and tariff data, session state, billing data, user preferences. Out: Driver actions (session start/stop, payment), fleet manager reports, branded customer touchpoints. Breaks at the second country — AFIR-compliant ad-hoc payment, jurisdiction-specific price transparency and localized workflows cannot be retrofitted into a single-market app without a rebuild.

The four layers are not interchangeable, and the scaling failure modes look nothing alike. OCPI roaming breaks at the protocol edges when you add a CPO whose implementation interprets the spec differently. Authentication breaks at velocity: token spoofing, session hijacking, and RFID abuse scale nonlinearly with driver count. Billing breaks at the tariff pipeline when a CPO changes mid-session pricing and your driver-facing price display drifts out of sync. Driver experience breaks at the second country, because AFIR-compliant ad-hoc payment in Paris is a different product from session-based billing in Warsaw.

Each layer has a different engineering center of gravity. Treat them as a single “platform feature list” and you will staff the project wrong, test it wrong, and ship a stack that looks complete until the first real scaling event.

The Architectural Decision Hiding Inside “Platform Choice”

When teams pick an eMSP platform by comparing vendor feature checklists, they are answering a question the checklist cannot see. The real question is which of four architectural levers you control, and which ones the vendor controls for you.

The four levers are: OCPI implementation depth, billing flexibility, driver experience ownership, and multi-market scalability. Every eMSP platform implements some version of all four. The depth of control you have over each one determines whether your platform can still serve your business in 18 months, when the market, the regulations, and your own strategy have moved on.

A SaaS eMSP platform typically surfaces the first two levers as configuration (which CPOs to connect to, which tariff rules to apply) and hides the other two as product decisions (driver app look-and-feel, multi-market support as a vendor roadmap item). A custom-built platform exposes all four, at the cost of building everything yourself. An accelerator-plus-custom model exposes all four with a pre-certified protocol layer, which is the option most teams do not realize exists until they are already stuck.

We cover each lever in depth below. The framework is not academic: it is the checklist we use with clients who come to us 12 months into a SaaS implementation and ask why the platform won’t do the thing they just signed a contract for.

Build vs. Buy vs. Accelerator + Custom: eMSP Platform Software Development Paths

The highest-stakes decision in any eMSP project is the development path. Get it wrong and the cost is 12 to 18 months and a missed market window. The three paths have distinct cost structures, risk profiles, and ceilings on what the finished platform can do.

eMSP Platform Development Paths — Build vs. Off-the-Shelf SaaS vs. Accelerator + Custom
Decision Factor Build from Scratch Off-the-Shelf SaaS Accelerator + Custom
Time to first production: How fast you launch 12–18 months, with the first 6 months consumed by the OCPI protocol layer alone Weeks to a few months (configuration-led onboarding) 3–4 months for a production-ready platform including full OCPI 2.2.1 and hub connectivity
OCPI coverage: Protocol depth Whatever the team builds — typically partial OCPI at launch, completed iteratively under pressure Varies by vendor; certification evidence and hub integrations should be verified, not assumed Full OCPI 2.2.1 delivered as pre-certified components, with hub-based and bilateral channels on day one
Billing flexibility: Commercial models supported Unlimited — but typically built for one model first and rewritten when the second is added Limited to the vendor’s billing product; multi-model support varies and is often an upgrade tier Subscription, pay-as-you-go and B2B fleet models on one backend, because the architecture is exposed and modifiable
Source code ownership: Who owns what Full ownership of everything built Vendor-owned; no source code access, no ability to extend the platform internally Full ownership under a perpetual license — both the protocol layer and any customizations your team builds
Scaling economics (5-year TCO): Cost trajectory Very high — engineering team plus certification plus maintenance plus opportunity cost of delayed launch SaaS subscription scales with enrolled drivers or sessions — high at portfolio scale, lower early Fixed perpetual license plus T&M implementation; no per-driver scaling fees at any volume
Multi-market readiness: AFIR, state rules, data sovereignty Possible but requires regulatory expertise the engineering team usually does not have Depends entirely on the vendor’s market roadmap — you wait for the vendor to add each new jurisdiction Jurisdiction-specific extension points can be added as the business enters each market, without forking the codebase
Driver experience ownership: White label depth Full — the driver app is your product from day one Constrained — typically a white-skinned vendor app with limited customization Full — the application layer is yours and can be forked per customer segment (consumer, fleet, utility, automaker)
Risk profile: Primary failure modes Protocol complexity gap and certification delays are the common failure modes; VC-backed teams commonly miss milestones by 6+ months Platform dependency, vendor roadmap drift, and scaling cost exposure as enrolled drivers grow Requires engineering ownership of the application layer — not suitable for teams without a software product capability
Best fit: Who should pick this path Large operators with dedicated protocol engineering teams and genuinely unique program requirements Very small operators running a single-market, single-model pilot with no intention to extend Mid-market CPO/eMSP operators, enterprise entrants, utilities, OEMs and technology providers who need protocol compliance fast without sacrificing architectural control

The build path is the most visible but rarely the right one for a first eMSP platform. It offers unlimited flexibility, but the protocol layer (OCPI 2.2.1, roaming hub connectivity, CDR processing, tariff management) typically consumes 12 to 18 months of engineering time before the business logic on top can start. For a VC-backed eMSP, that is the difference between hitting the Series A milestone and burning through runway explaining why.

The off-the-shelf SaaS path offers fast time-to-production but caps the architectural levers at what the vendor exposes. The trap is not the sticker price; the trap is the per-driver or per-session scaling fee that compounds against you as enrolled drivers grow. SaaS also locks the driver experience to the vendor’s app or a constrained white-label version, which is good enough for a pilot and rarely good enough for a branded commercial product.

The accelerator-plus-custom path is the option most teams do not know exists. A pre-certified OCPI implementation delivered as a production-ready codebase compresses the 4-6 month protocol build into weeks, with certification already passed. The client owns the source code outright, retains IP for every customization built on top, and pays no per-driver scaling fees. This is how Codibly’s eMSP Engine is built: the commodity protocol and roaming infrastructure comes pre-built and pre-certified. The differentiating product logic (your billing model, your driver experience, your fleet portal, your tariff engine) is what your team writes on top. If you want to see how this works in practice for eMSP buyers specifically, that page is the implementation reference.

Which path fits depends on two questions: how customized your eMSP product needs to be, and whether you can afford the protocol certification timeline. For most mid-market CPO/eMSP operators and enterprise entrants, the accelerator path is the one that fits both constraints without compromising either. For a deeper treatment of build-vs-buy economics as they apply to the Codibly implementation model, see our eMSP Platform Solutions service page.

Lever 1 — OCPI Implementation Depth: Why Partial OCPI Caps Your Growth

Every eMSP vendor says they “support OCPI.” Very few support full OCPI 2.2.1 across all modules, all edge cases, and all hub connections. The difference is where your growth ceiling lives.

Full OCPI 2.2.1 means the platform implements the Locations module for CPO charging station data, the Tokens module for driver credentials, the Tariffs module for real-time pricing, the Sessions and CDRs modules for session lifecycle and settlement, the Commands module for remote start/stop, and the Hub Client Info module for roaming hub integration. It also means the platform handles the asymmetries in how CPOs implement each of those modules — because the spec leaves room for interpretation, and every large CPO network has quirks that only show up when you try to onboard a driver whose session spans two markets.

Partial OCPI, the “we support token authorization and CDRs” version of the spec, works for the first ten CPO connections. By the thirtieth, the custom integration work is consuming more engineering time than the original platform build did. By the fiftieth, the team is rewriting the protocol layer in production. We have seen this failure mode often enough to make it the first thing we stress-test when a client inherits an existing eMSP platform.

The second question inside Lever 1 is hub-based vs. bilateral OCPI. Roaming hubs like Hubject and Gireve aggregate CPO connections behind a single OCPI interface and accelerate coverage — you get access to thousands of charge points through one integration. The trade-off is per-session fees and less control over the CPO relationship. Direct bilateral OCPI agreements are more cost-efficient at scale and give you direct commercial terms with each CPO, at the cost of longer onboarding for each new connection. A well-architected eMSP platform supports both simultaneously, using bilateral channels for anchor CPO relationships and hub-based connections for coverage breadth, and it routes authorization, session, and CDR traffic through the right channel without the application layer caring which is which. For the full protocol treatment, see our OCPI Protocol Guide and the deeper comparison in OCPI vs. OICP. And for teams new to the OCPI/OCPP distinction, OCPI vs. OCPP explains how the two protocols complement each other across the CPO and eMSP sides of the stack.

If you need the protocol layer delivered as a production-ready component rather than a 4-6 month development project, Codibly’s OCPI Accelerator and the eMSP Engine both ship with full OCPI 2.2.1 support and the roaming hub connectors already integrated.

Lever 2 — Billing Flexibility as an Architectural Choice

Most eMSP billing failures are not billing bugs. They are architectural commitments made early in the platform build that cannot be undone without a rewrite.

The commitment looks like this: the team builds a billing engine optimized for one revenue model (subscription, pay-as-you-go, or fleet B2B) because the first market the eMSP serves only needs that one. Six months later, the business adds a second model, such as a fleet contract layered on top of consumer subscriptions, and the billing engine cannot represent both models on the same backend without a fundamental redesign. The fix is rarely quick.

A scalable eMSP platform supports all three commercial models simultaneously on one codebase: flat-fee subscriptions with optional session overages, pay-as-you-go per-kWh or per-minute pricing, and B2B fleet contracts with per-vehicle reimbursement data and VAT-compliant reporting. The architectural discipline is in separating the CDR ingest layer (what actually happened during the session) from the pricing layer (what the driver or fleet account should be charged), so the same session data can feed multiple pricing rules without double-counting or drift.

Tariff propagation is the second architectural challenge inside Lever 2. OCPI delivers tariff data from CPOs in near-real-time, but a driver-facing price display that drifts out of sync even briefly creates regulatory exposure in markets with consumer pricing transparency requirements. Under the EU’s Alternative Fuels Infrastructure Regulation (AFIR), operators are required to display accurate session pricing before the driver authorizes a session, and to provide ad-hoc payment access for drivers without a pre-existing account. A platform whose pricing pipeline was architected for single-market, subscription-only drivers cannot meet these requirements without retrofitting. The retrofit cost is typically higher than the original build.

Lever 3 — Driver Experience as Software Product, Not Vendor Skin

There is a difference between a white-label eMSP and a white-skinned vendor app. The first is a software product your team owns, which your users perceive as your brand, and which you can extend as your driver segments diversify. The second is a vendor’s app with your logo on the header.

The difference matters commercially. If your eMSP operates as a utility offering a branded charging service to ratepayers, a fleet operator offering charging as an employee benefit, or an automotive OEM bundling charging into vehicle purchases, the driver experience is a core product — not a configuration screen. A vendor-owned app limits how the product can evolve: which screens can be customized, which APIs can be extended, which data can be surfaced to the driver. In every case the vendor’s roadmap becomes your roadmap, whether you like the velocity or not.

Architecturally, a white-label eMSP platform separates the driver-facing application from the backend services behind clean APIs (authentication, tariff display, session management, billing history) so multiple branded front-ends can be built on top without forking the backend. A mid-market CPO/eMSP we worked with recently launched with a single branded consumer app; nine months later, they added a separate fleet portal for B2B customers with different workflows and authentication requirements, then a partner-branded app for a utility customer, all sharing the same backend platform. That pattern only works when the application layer is architected as a product surface, not a vendor skin.

The architectural implications cross over into CPO territory for operators who run both roles simultaneously. Our White Label EV Charging Software article covers the driver-side patterns in depth; the White Label CPO Platform companion piece covers the operator-side equivalent for charge point operations. If you are building both layers, read both. The architectural decisions compound. For the driver-app-specific treatment, Codibly’s Driver Apps service page covers the commercial and technical options.

Lever 4 — Multi-Market Scalability: AFIR, Regional Tariff Rules, and Data Sovereignty

An eMSP platform that works in one market is not an eMSP platform that works in two. The regulatory, tariff, and data-residency differences between jurisdictions are not configurable switches. They are architectural commitments.

In the European Union, the Alternative Fuels Infrastructure Regulation (AFIR) imposes requirements on price transparency, ad-hoc payment access, and session data reporting across all member states. Operators must display per-kWh pricing before the driver authorizes a session; they must offer ad-hoc payment methods (contactless card or QR code) without requiring account registration; they must report usage data in formats the Commission has specified. These are EU-wide requirements, but the national implementation details vary enough that a platform architected for a single market often needs retrofits to cross the border.

In the United States, the regulatory landscape is more fragmented. State-level price transparency rules, weights-and-measures certification for metering accuracy, tax treatment of EV charging as fuel or utility service, and regional ISO/RTO programs all create per-market divergence. A platform built for California will not launch cleanly in Texas without adaptation, and a platform built for either will not launch cleanly in Europe.

Data sovereignty is the third dimension. Several European markets have explicit requirements that driver data, session data, or billing data be stored within specific jurisdictions. A platform architected as a single global database has to be rearchitected as a federation of regional databases with synchronized metadata — which is significantly harder than it sounds, because the interactions between roaming sessions, cross-market tariffs, and settlement reconciliation cross the data sovereignty boundary constantly.

The architectural pattern that survives multi-market expansion is jurisdiction-specific extension points. The core platform handles the 80% of functionality that is identical across markets, and each market-specific regulation plugs in as an extension module: tariff display rules, payment method requirements, data residency, reporting formats. Without those extension points, every new market is a fork. With them, every new market is a configuration file and a compliance test.

Accelerators: Closing the Gap Between SaaS Speed and Custom Ownership

The argument between building an eMSP platform from scratch and buying a SaaS product assumes there are only two options. There is a third, and it is the one most eMSP operators adopt once they understand what it does.

An accelerator model ships the certification-critical protocol layer as a production-ready, pre-tested, pre-certified component that teams embed in their custom platform. The protocol layer itself (OCPI 2.2.1 with hub connectivity, CDR processing, tariff management, and token authorization) is standardized by specification and does not differentiate one eMSP from another. The business logic on top, which billing models to support, which driver segments to serve, which markets to enter, how the driver experience feels, is where every eMSP competes and every eMSP wants to own.

Codibly’s eMSP Engine is the accelerator we built for this exact pattern. The engine delivers the full OCPI 2.2.1 implementation, roaming hub connectivity (Hubject, Gireve, direct bilateral), session lifecycle management, CDR processing, and tariff engine as a perpetual-license codebase. The client owns the source, modifies what they need to, and builds the commercial and experience layer that differentiates their product on top. Implementation timelines compress from 12-18 months to 3-4 months for a production-ready launch. There are no per-driver scaling fees, no vendor lock-in, and no dependency on a third-party roadmap.

The pattern generalizes beyond eMSP. We have used the same model to deliver protocol certification in 6-8 weeks for clients across OCPP, OpenADR, and IEEE 2030.5. The same argument applies every time certification is the gate between development and revenue. For eMSP specifically, the eMSP Engine is the implementation reference.

Case examples illustrate the pattern across market segments. A leading global technology solutions provider building an eFleet aggregator platform for utilities used multi-protocol support (OCPP, MODBUS, ChargePoint API) to achieve hardware-agnostic DR participation and verified load reductions across utility demand response programs — the multi-protocol architectural pattern in Lever 1 made the project viable across heterogeneous charger fleets. Flux, a V2X energy exchange platform, used a similar architectural approach to validate vehicle-to-everything energy flows with major automotive OEMs, treating the protocol layer as pre-built infrastructure and building the V2X-specific business logic on top. And IMP PAN’s scalable OCPP server for an H2020 research program demonstrates the same architectural discipline at the CPO side, with pre-certified protocol as the foundation and custom logic as the differentiator.

These are not all eMSP projects individually, but they share the architectural pattern that makes eMSP platform software development work at scale: own the application layer, license the protocol layer, and refuse to accept either as an all-or-nothing choice.

Making the Decision: A Four-Lever Checklist for eMSP Platform Software Development

If you are deciding how to develop your eMSP platform this quarter, the four-lever framework becomes a practical checklist. It is the same checklist we walk clients through in scoping workshops, and it compresses a 6-month evaluation into a week.

Lever 1 — OCPI implementation depth. Does the platform you’re considering implement full OCPI 2.2.1 across all modules, with certification evidence? Does it support hub-based and bilateral roaming simultaneously on one codebase? Can you see working connections to major European and North American CPO networks? If the answer to any of these is “partial” or “on the roadmap,” treat that as your ceiling.

Lever 2 — Billing flexibility. Can the platform support subscription, pay-as-you-go, and B2B fleet billing on the same backend, simultaneously, without a data migration? Can the tariff pipeline keep driver-facing prices accurate across 100+ CPO connections? Does the platform support AFIR-compliant price display and ad-hoc payment out of the box? If your answer to the first question is “pick one,” the platform will become your constraint as soon as the business adds a second commercial model.

Lever 3 — Driver experience ownership. Is the driver-facing application a product surface you can extend, or a vendor app with your logo on it? Can you fork the app for a fleet customer without rebuilding the backend? Who owns the code that touches your customers every day?

Lever 4 — Multi-market scalability. Does the platform architecture separate core functionality from jurisdiction-specific extension points? Can you plug AFIR compliance into the European deployment and weights-and-measures certification into the US deployment without forking the codebase? Where does data residency live in the architecture?

Most teams find that a full SaaS product answers “partial” to at least two of these, a full custom build answers “yes” to all four at a cost of 18+ months, and an accelerator-plus-custom path answers “yes” to all four in 3-4 months. That is the economic case for the accelerator model, made explicit.

If you want to talk through how the levers apply to your specific eMSP product (market, driver segments, billing requirements, expansion plans), the implementation reference is our eMSP platform software development service page, and the accelerator itself is documented on the eMSP Engine page. The right place to start depends on where you are in the evaluation; the right time to start is before you sign the SaaS contract.