How many bugs are sitting in your backlog?

Every software project I've worked on had the same pattern. The bug backlog just keeps growing. Non-critical issues get deprioritized, postponed, forgotten. Before you know it, there's a pile of small problems that nobody ever gets around to fixing.

We decided to take a different approach — to break out of that endless cycle of deprioritization.

Our goal is to keep the number of open bugs as close to zero as possible.

In charging infrastructure, absolute stability of SaaS services isn't optional. It's the baseline. A bug in our platform isn't a cosmetic issue. It can mean real customers standing in front of a charging station, unable to charge their vehicle.

We've seen this problem before, in our shared mobility days. Just like with charging stations, the few minutes a user spends in the application need to be rock-solid. That's how you build trust. That's how you get people to come back.

Why this isn't optional for charging infrastructure

Every bug in our charging platform costs our customers money and trust. Charging infrastructure isn't a web app where you can just reload the tab. The station's status needs to be available and transparent at all times. When issues occur, they need to be traceable for the end customer — giving them a chance to resolve the problem on site. Though obviously, the ideal experience is that no problem occurs in the first place.

Here's a concrete scenario: 50 new charge points go live. The press release is out. The CPMS reports all stations as "online." And then the customer-facing product breaks — the QR code won't scan, or the app crashes because it wasn't properly tested with real users. What's left is reputational damage that no marketing campaign can undo. A CPMS keeping the station "online" is just the first step. Once that's given, there MUST be a top-notch experience for end customers who don't know what a CPMS is and expect the same reliability they get at a petrol pump.

Software quality in this industry isn't a nice-to-have. It's the prerequisite for physical infrastructure and end-customer applications to actually work reliably.

The core idea

One of our inspirations was Linear, from the product management space. They showed that you can consistently prioritize quality without slowing down. The basic idea is actually quite simple:

Fixing a bug takes the same effort whether you do it today or in six months. But if you fix it today, every user has a better experience starting tomorrow. So why wait?

"A growing bug backlog is often a sign that quality isn't truly a priority. We want to do things differently."

In practice, this means: every bug either gets fixed promptly or gets consciously closed as "Won't Fix." Nothing in between. No "we'll look at it later," no quietly pushing it to next quarter. Instead, clear communication to our customers — so they can communicate clearly to theirs.

How we actually put this into practice

The implementation is less complicated than you'd expect. Three principles carry the whole thing:

Triage on arrival

Every bug gets triaged immediately. Whether it comes from a customer, from automated monitoring, or from the team itself — it gets a severity level and an owner. Same day.

Clear SLAs

We've set ourselves internal time windows:

Critical (P0): Fix within 4 hours — when charging sessions are affected
High (P1): Fix within 24 hours — significant feature impairments
Normal (P2): Fix within 5 business days — smaller issues with no direct operational impact

Every morning, the rule is: bugs first, features second. Always. Sounds uncomfortable, but it prevents the pile from ever building up.

No bug backlog

This is the principle that demands the most discipline. We don't postpone bugs. Every bug either gets resolved promptly or gets closed deliberately — because a list that grows for months? Nobody ever works through it.

Transparency over excuses

Our zero-bug policy isn't an internal promise gathering dust on some Confluence page. It's a promise to our customers.

On our public status page, every customer can see in real time how our systems are doing — including planned maintenance and historical availability. No hiding behind "we're looking into it."

In the worst case, we'd have to push back feature commitments. If there were ever that many bugs. From our perspective, though, that's a trade-off we're happy to make. A known, stable experience for end customers across the current feature set has absolute priority. Our customers should be aware of that too.

After major incidents, we write post-mortem reports: what happened, why, and what we're changing to prevent it from happening again. We share those with affected customers. And our monitoring typically catches issues before anyone even needs to open a ticket.

This fundamentally changes how we work with our customers. Instead of writing a frustrated ticket and waiting weeks, they find that problems are often resolved before they even notice them.

What this does to the team

A zero-bug policy doesn't just change processes. It changes how a team writes code.

When everyone knows that a bug won't disappear into some backlog but will land on their own desk the next morning, there's a natural incentive to work more carefully. Tests become second nature. Code reviews get more thorough. Not because there's a rule — but because the consequences are felt personally. Where possible, the developer who wrote the code is automatically responsible for fixing the bug too.

That has a welcome side effect: without legacy bug debt, there's significantly more time for development. New features instead of old problems.

What this means for your charging infrastructure

If you're operating charging infrastructure, you depend on the software behind it working reliably. Stations need to be reachable, payment flows need to go through, and systems need to stay stable under heavy load.

Our zero-bug policy is how we live up to that standard. Not a marketing promise — but a daily practice, visible in our work, in our post-mortems, and in how we communicate with our customers.

If you're looking for a platform where quality, transparency, and stability aren't just lip service — let's talk.