- Identity and access management across B2C and B2B
- Driver profile management
- Email and password login and logout
- Password reset
- Personal data editing by the driver
- Account deletion
- Linking a driver to a contract
Codibly eMSP Engine
Build your brand. Own your e-mobility service.
A production-ready e-mobility service provider platform, handed over with its source code. A white label eMSP platform you license once, build into your own branded product, and run on infrastructure you control.
Who it’s for
Three businesses, one core
The Engine is the same codebase whichever of these you are. What changes is the shape of the customization and the size of the license, which is why the first conversation is a scoping session rather than a price list.
ev_station
e-mobility service providers outgrowing SaaS
You launched on a rented platform and it got you to market. Now the per-driver line grows every time your user base does, the features that would differentiate your service sit behind someone else’s backlog, and your app is recognizably the same app three competitors are running.
groups
Fleets running charging as a benefit, not a business
Your drivers charge at depots, at public networks and at home, and the reimbursement logic that ties those together is specific to your company. A multi-tenant schema built for public retail charging will not hold it.
badge
Retailers extending an existing loyalty relationship
You already own the customer, the card and the points. Charging is a new line in a relationship that predates it by decades, and the value is in connecting the two rather than in running a separate charging app beside them.
The choice
There is a third way to own your eMSP platform
There are two usual ways to get e-mobility service provider software. Renting is genuinely the fastest route to a live service and the cheapest to start, which is why most providers begin there. Building in-house gives you exactly what you want and takes twelve to twenty-four months to give you any of it. The third position is the one this page sells: a proven core, customized to your business, handed over with the code.
We argue the whole decision, cost structure, ownership, customization, roadmap control and exit, on a page of its own: Build, buy, or own your charging platform.
The argument
What ownership actually changes
Ten things that are true of a platform you own and not of one you rent. None of them is a feature. All of them are consequences of where the code lives and whose name is on the product.
code
You own the code, not just the license
Full source-code ownership means no vendor can raise your price, change your terms, or retire a feature your business runs on.
paid
Growth in drivers stops being a billing event
A one-time license rather than a fee per driver or per transaction, so your platform cost stops tracking your user base. Scaling users without linearly scaling cost is the whole financial argument.
palette
Your app is your product
Not a shared app with your logo in the corner. The interface, the language and the flows that make the service feel like yours are yours to design, because the front end is built for you rather than configured from a menu.
badge
Loyalty logic that is actually yours
Cards, rewards history and promotions sit inside the platform rather than in a partner’s, so the offer you invent next quarter does not need anyone’s product team to agree it is worth building.
account_tree
You control the roadmap
Your team, or ours under a support agreement, extends the platform on your timeline. No queueing behind other customers for a feature request.
hub
Roaming is built in, not bolted on
The OCPI layer ships with the core and is proven in delivery, so coverage is a commercial negotiation with networks rather than an engineering project each time.
shield_locked
Driver data sits in your infrastructure
Names, journeys, payment tokens and consent records live where your security function decides they live. That is what makes a residency answer possible, and what makes a GDPR review something you can pass rather than something you inherit.
savings
Lower long-term TCO, even after the build
Past a moderate user base the multi-year cost curve is flatter than a subscription’s. Up to 70% below a full custom build to get there, because the core already exists and is already tested.
security
Less exposure to someone else’s business risk
If a platform vendor is acquired, pivots or shuts down, an owned codebase insulates you from a decision you had no part in.
support_agent
Expert support without a dependency
Codibly can carry ongoing development. That is a choice you make each year, not a structural requirement for keeping the service running.
Capability
What ships before we customize anything
Most white label eMSP platforms are a shared product with your logo applied to it, and the shape of your service is the shape of theirs. This is the shipping feature set of the Engine core, in the license, before any customization. The seventh group is the work that gets scoped around your market rather than assumed.
- Drivers, identity and accounts
- Contracts, tariffs and loyalty
- Charging sessions and authorization
- Roaming and charger data
- The driver journey
- Billing, admin and platform
- Scoped to your market in customization
- Contracts management for individuals, companies and fleets
- Tariff, pricing and promotions management
- Loyalty: cards, rewards history and promotions
- Fleet account management
- Charging session management end to end
- Authorization management
- Token management for RFID and app credentials
- Remote start and stop
- Autocharge
- Charge detail record management
- The OCPI layer for CPO integration, covered in depth in OCPI and OICP interoperability
- Charger and location data management
- Charger list, search and filters
- Chargers on a map, with user location detection
- QR code scanning that opens a charging session
- Live session view: duration, energy in kWh and running cost
- Session history and per-session detail
- Built as your app rather than handed over as a generic one. Our approach to EV driver apps explains why that distinction matters
- Invoice management: lists, templates, settings and XML output
- Admin panel
- eMSP dashboard
- Infrastructure setup and CI/CD
- Subscription and recurring billing models, built to your commercial design
- Tax and VAT handling for the jurisdictions you operate in
- Regulatory alignment, including AFIR reporting and anti-fraud rules, built to what your market actually requires
- Payment service provider integration, to the provider you already use
- Charger detail, connector and live availability display, tuned to the data your roaming partners return
- Driver and fleet registration flows, including the validation and consent steps your legal team specifies
Interoperability
Roaming-agnostic by construction
An eMSP is only as good as the chargers its drivers can actually use, and none of those chargers are yours. The Engine ships with the roaming layer already built and already proven in delivery, and keeps it separate from your commercial logic, so coverage grows by negotiation rather than by re-architecture.
compare_arrows
OCPI 2.1.1 and 2.2.1
The CPO integration layer ships in the license: locations, tariffs, sessions and charge detail records across multiple countries through one API. The same layers sit under the CPMS Engine on the operator side of the transaction.
hub
Hubject, OICP and bilateral agreements
The integration layer is abstracted from your pricing, contracts and loyalty rules, so adding a roaming hub or a direct agreement with an operator is an integration rather than a rebuild. Codibly has built and operates OICP and Hubject connections in delivery. Specific hub and partner connections are scoped per connection.
ev_charger
Autocharge, and Plug & Charge through Hubject
Autocharge ships with the core, so a returning driver is recognized by their vehicle rather than by opening an app. ISO 15118 Plug & Charge is supported through Hubject where the operator side implements it.
Delivery
From workshop to handover
Weeks, not quarters, because roughly 80% of what an eMSP needs already exists, is already tested and is already carrying drivers elsewhere. The variable is customization depth, and that is what the first phase exists to establish. Nobody can quote you a date before it.
edit_document
Scope
- Requirement workshops with your team: commercial, billing, security, brand, and whoever will own the service afterwards
- Scope agreement, with delivery costed against it rather than against a template
- Milestones and contract agreed before anyone writes code
code_blocks
Build
- The Engine core is deployed into your cloud on Docker, Terraform and Kubernetes, cloud-agnostic and Azure-compatible
- Customization built against the scope: your tariffs, your loyalty mechanics, your integrations, your brand
- Roaming tested against live operator endpoints, not only against a simulator
chip_extraction
Migrate and transfer
- Migration of the driver base, contracts, token estate and session history you are entitled to take
- Documentation, architecture guides, training and knowledge-transfer workshops
- Handover of the codebase, the infrastructure and the operational knowledge, in your hands. Also available as a Build-Operate-Transfer engagement where you want us to run it before you take it
After handover
Who runs it afterwards is your call
Two routes, and we are genuinely indifferent between them. Either way you own the platform. The only question is whose people operate it.
engineering
Run it yourself
Your team takes the platform and operates it. That is what the handover is designed to make possible, and it is the route that makes the ownership argument literal rather than rhetorical.
support_agent
Have us run it
Codibly maintains it under contract: health checks, security patches, performance monitoring and preventative maintenance. You still own the code. You have simply chosen not to staff for it.
library_add
What handover includes, either way
Technical documentation, system architecture and operational guides, team training sessions and knowledge-transfer workshops. Ad-hoc support and future enhancements are scoped per request rather than bundled into a retainer you may not need.
How pricing works
A one-time license, tiered to the size of your company and your network. No per-driver fee, no per-transaction fee, no revenue share, which are the things that make a rented platform more expensive every year you succeed. Customization is scoped and priced separately, after the workshop that defines it, because pricing it before then would be a guess dressed as a quote.
What that comes to for a business your size is a conversation. Bring us the service you actually run.
For the buying committee
Take it to your team
Owning your e-mobility platform is a decision your finance, procurement, security and engineering colleagues all have a stake in. Four short briefs, each answering their questions directly, so you can forward one rather than translate the whole case.
paid
For the CFO
The capital-versus-operating case, honestly drawn: where an owned platform is more expensive (year one) and where the curves cross. Includes what “no per-driver fee” is worth against a growth plan, and what is genuinely still recurring.
handshake
For procurement
Ownership and exit in contractual terms: what transfers at handover, what Build-Operate-Transfer commits both sides to, what happens if you want to leave, and what happens if we do.
verified_user
For the CISO and the DPO
Where driver data lives and who can reach it: your infrastructure, role-based access control, SIEM integration, encrypted tokens, and the GDPR artifacts your security and privacy functions will ask for before sign-off. Personal data at driver scale is the reason this brief is longer than its CPMS equivalent.
integration_instructions
For the technical and CX lead
The capability set, the roaming layer, the stack you inherit (Docker, Terraform, Kubernetes), and an honest account of what customization on top of the core actually involves.
Delivery in progress
One core, three enterprise programs
The same Engine core sits under charging platforms for a European energy group, a Gulf charging network and a global carmaker, three very different businesses, three very different builds. Anonymized at each client’s request.
public
A major Central European energy corporation
Codibly is building the CPMS platform on its Engine for one of the region’s largest integrated energy groups.
hub
A Gulf-region charge point operator
The same core is in delivery for a charge point operator scaling a national network.
directions_car_filled
A global automotive OEM
An OEM-grade charging management platform, built on the same core.
Case studies
Published work from the same delivery record
Frequently asked questions
You own it. The Engine is delivered as a one-time perpetual license with full source-code ownership. The customized codebase is yours to modify, extend, fork or hand to another supplier. There is no clause that returns it to us, and no runtime dependency on anything we host.
Both words are doing work. It is white label in the sense that the core already exists, is already tested and is not built from zero. It is yours in the sense that the front end is built for your brand rather than configured from a vendor’s theme editor, and the source is handed over at the end. What you cannot get from a white label product bought as a service is the second half of that sentence.
That is what the OCPI layer is for, and it ships with the core rather than being added later. It carries locations, tariffs, sessions and charge detail records between you and charge point operators across multiple countries through one API. Roaming hubs, including Hubject over OICP, and direct bilateral agreements with operators are both supported, and each specific connection is scoped as part of delivery.
The commercial logic is the point of customization: tariff structures, subscription models, loyalty mechanics, fleet and reimbursement rules, tax handling, the registration flows your legal team specifies, and the integrations into whatever you already run. The roaming layer and the core data model are what you are licensing precisely so you do not have to build them, though once the code is yours, even those are yours to change.
In your infrastructure, on your cloud account, under your retention policy. The platform is deployed to your estate rather than hosted by us, so residency, access control and retention are decisions your security and privacy functions make rather than terms they accept. Access is role-based, tokens are encrypted, and the platform can feed your SIEM. For a service holding names, journeys and payment credentials at driver scale, that is usually the difference between a review that passes and one that stalls.
Your side of the work is requirements, systems access, and decisions: a product owner who can settle commercial logic, someone from billing, someone from security and privacy for review, a brand or CX owner, and an integration contact per connected system. The commitment is heaviest in the scoping phase and during migration testing, and lightest through the build. The exact shape is one of the things the scoping session establishes, because it depends far more on how many systems you are connecting than on how many drivers you have.
Whichever you prefer. Your team can run it, and the documentation, architecture guides, training and knowledge-transfer workshops exist to make that a real option rather than a theoretical one. Or Codibly maintains it under contract. Neither changes who owns the platform. As for moving off it: nothing happens, because there is nothing to migrate away from. You are holding the source code, running it on your own infrastructure, with your data in your own database.
Contact us
Bring us the service you actually run
Not a demo of a generic app, and not a discovery call that turns into a pitch. A scoping session: what you run today, what it costs you per driver, what you would build if the roadmap were yours, and what the Engine would have to become to get you there.
