Inside Software Engineering at Easee
A fleet operator tells us that every card tap at one of their sites produces the same ID, no matter which card is used. Not a similar ID—the same one, on every charger.
Where do you start? Cloud configuration, firmware, the reader, or how the site is run? Cloud engineers, embedded engineers, and support worked through it together. They ruled out the cloud setting that could explain it, established that firmware doesn’t change tag IDs, and noticed that the site mixed remote starts with physical taps. Then someone suggested checking whether anything had been placed near the reader. It turned out to be close. An RFID tag stuck near the reader, with a QR code printed over it, was being picked up whenever another card was tapped. Two days after the first report, the case was closed.
That’s software at Easee. Our code runs in services, apps, and integrations connected to more than 1.1 million chargers. Now we’re building software to make that fleet useful to the power grid.
A million chargers change the questions
The problems you face at ten thousand chargers aren’t the same as those you face at 1.1 million. Hash collisions, endianness, and clock drift all emerged when we reached the low tens of thousands of devices. In 2020, sheer scale disrupted production for five days as synchronous device calls and assumptions about connectivity broke down.
We responded by breaking up the monolith, moving to asynchronous patterns, and building the foundations for safe progress: reusable deployment pipelines, unified observability, and a closer look at how much telemetry each device really needs to send. Today, our API runs at a 99.993% success rate across 15 billion requests. Our CTO and Head of Software shared the story, including the breakages, at NDC Oslo this September.
A charger on a weak cellular link isn’t a server in a data centre. Devices go offline, firmware versions differ, and the system still has to behave predictably.
Your API is someone else's building block
Installers, charging operators, energy companies, and home-automation providers build on Easee through REST, streaming, AMQP, and OCPP. A change to our API can disrupt a workflow at another company. That makes even small questions important: should an expired token with a rate-limited history return a 429 or a 401? How can an integration reconnect without hammering a service?
The API team is midway through a migration from checked-in specifications to a model where each service describes its own endpoints and a central pipeline deploys them. The details are where it gets interesting. OpenAPI 3 forbids optional path parameters, so a route that had worked for years had to be split in two. One bug came down to a single letter in an annotation. When a migration step dropped a few routes in production, our blameless postmortem led to a CI check that fails the build if routes disappear, per-API monitors defined as code, and a documented rollback path.
Platform and apps
The platform team builds the foundations: infrastructure as code, deployment pipelines, Datadog observability, and a better developer experience on AWS. A deploy that once required a runbook can now roll back safely. An alert that once fired after a customer noticed a problem now fires beforehand.
The apps team builds the experiences people use, in Flutter with native Swift and Kotlin where needed, across phones, tablets, watches, and in-car systems such as CarPlay and Android Auto. App problems often cross layers. Why does a load indicator show no percentage when a site has solar production? You trace the question from the UI through the API to the firmware and sometimes to the device on the desk beside you.
Software, embedded, and hardware work as one
Wingman, a shared library, gives cloud and embedded teams a common source of truth for products and charger commands. When the embedded team adds a command, such as a randomized start delay for grid-code testing, software exposes it in the portal. We deliver firmware to chargers in staged batches through a service we run. And when you need to understand a charger's behavior, the hardware is close enough to plug in and observe.
The next chapter is energy, not just cars
A large fleet lets us coordinate when energy is used, not just deliver it. In Great Britain, our partner Axle has built Flex Rewards into the Easee setup journey. Owners charge as usual and earn rewards for helping balance the grid, while Axle makes small adjustments to when a session draws power and keeps to the driver's schedule.
Behind this experience is software we're building: services that report consumption, respond to grid signals, and turn them into dependable charger behavior. Flexible charging shifts when demand occurs. It doesn’t mean every car sends power back to the grid, though that remains the longer-term direction.
How do you turn an energy-system signal into device behavior you can trust while ensuring the car is ready by morning? If you understand flexibility or grid services, you can help shape the answer. You don’t need an automotive background.
Our stack, and who thrives in it
Our core backend is C# and .NET on AWS, with infrastructure as code and Datadog. Engineers with Java or Go backgrounds can bring relevant experience: concurrency, designing for failure, and running distributed services matter more than syntax. OCPP experience is a plus.
We value curiosity about why something failed, a willingness to look beyond your usual layer, and the habit of documenting what you learn. Our postmortems are blameless, and a weekly Fire Chief rotation keeps everyone close to the issues customers and partners encounter.
What you'd work on
- APIs: complete the gateway migration without surprising partners, and make our integrations easier to build on.
- Platform: make deployment, observability, and rollback safer as the fleet grows.
- Apps: deliver a reliable experience across phones, watches, and cars.
- Flexible energy services: turn grid signals into dependable charger behavior, market by market.
Build what comes next
Somewhere right now, a charger is losing a weak cellular connection, a partner is building on an API you could help shape, and a grid signal is waiting to become a charging schedule. If you want to work on these challenges, we’d like to hear from you. When you apply, tell us about something that broke in production and what you learned from it. It’s a quick way to show us how you think. See our open roles: career.easee.com/jobs