An EV Charging Platform Built from Scratch, OCPP to App

The challenge

They had chargers. They had no software.

That's a harder starting point than it sounds. An EV charging business without a platform can't do the things that make it a business: a driver can't find a free charger, can't reserve one, can't pay for a session, and the operator can't configure tariffs or see what any unit is doing. The hardware is only half a product — the other half is the system that turns a box on a wall into something a customer can actually use.

Nothing existed to build on. No platform to extend, no vendor system to migrate off. Everything from the protocol layer up had to be built.

What we built

Three surfaces on one platform, all developed in-house.

The charge point layer — OCPP 1.6J. The platform speaks Open Charge Point Protocol 1.6J, the industry standard, which means charge points talk to the system over a common language rather than a proprietary one. Sessions start and stop, meter values flow back, and units report their state without being tied to a single hardware vendor.

The driver mobile app — built in React Native, shipped on both iOS and Android. What a customer actually touches:

• Find a station — where the chargers are and which are free.
• Reserve a bay before arriving.
• Charge, with the session controlled from the phone.
• Pay online when the session ends, through iPay88 and 2c2p.
• Collect points, so repeat use is rewarded.

The backoffice. An operations console for running the network without a developer in the loop:

• Charge points, chargers, and charging sockets — the physical hierarchy, configurable down to the individual socket, across sites nationwide.
• Transactions — every charging session, searchable.
• Reports — usage pulled per charge point.
• RFID cards — issuing and managing the cards drivers tap to start a session.
• Car barrier administration — the reserved-bay hardware, managed as a first-class part of the system.
• Access control, audit logging, and messaging — who can do what, what they did, and how drivers get notified.

The backend is Express on TypeScript.

The reservation problem worth explaining

Letting a driver reserve a bay in an app is easy. Making the reservation mean something is not — because nothing stops another car parking in it.

We solved it in the physical world: the platform drives a car barrier over MQTT, so a reserved bay stays physically blocked until the driver who booked it arrives. MQTT is a lightweight messaging protocol suited to exactly this kind of always-connected hardware.

That's the difference between a booking feature and a booking that works. It's also the sort of requirement that only surfaces once you take a software system seriously as part of physical infrastructure — and the sort that off-the-shelf charging software rarely accommodates.

The results

The full platform — protocol layer, mobile app, and backoffice — went live within a year, including complete testing, and is still running in production today.

It currently runs 28+ charging sockets across 10+ sites, serving 400+ registered drivers.

That "still running" matters more than the launch date. Plenty of systems ship; the ones worth citing are the ones still carrying real traffic and real payments long afterwards.

Testing is worth calling out rather than glossing over. Charging infrastructure fails in ways a normal web app doesn't: hardware drops connections, sessions interrupt mid-charge, payments must reconcile against energy actually delivered. Getting that right is most of why the timeline is measured in a year rather than a quarter, and it's not a phase to compress.

Building something similar?

Hardware-connected platforms are their own discipline — protocol compliance, unreliable connections, and physical state that has to stay in step with what your database believes.

If you're building in this space, get a free consultation. And if you're weighing custom against off-the-shelf more generally, our guide to white-label versus custom development covers where each one wins.