From low code to philosophy - how ChargeGuru learnt to scale custom apps without chaos

When Laurent Salomon took over as Head of Engineering at ChargeGuru he quickly realized he was in for an exciting ride.

The company was a rapidly growing B2C marketplace for electric vehicle charging infrastructure. At the same time, the organization was moving closer to its sister business, Zeplug, which operated a complementary B2B charging network.

But with two tactical IT estates built for speed of implementation during the start-up phase — and an increasingly complex international regulatory environment — the combined organization was in danger of slowing down in the face of IT that was difficult to adapt and scale in line with the business’s growth.

Salomon explains that this is the environment into which he was recruited — with a mandate to help turn the company’s ambitions into a scalable and adaptable technology foundation. In effect his job was to keep the whole business moving as he rebuilt its technology from underneath — all while making sure that the wheels didn’t come off in the process:

This is why I was recruited — I’m an open-source engineer. I know how to code. I know how to architect systems.

Salomon says that he quickly identified a structural problem in the company’s use of Salesforce:

Salesforce was the backbone — which was a good bet to get going quickly — but it was heavily customized. And the maintenance was hard. But rebuilding everything was also not smart — because you don’t want to reinvent the wheel or break something that works.

In other words, the company’s heavily customized Salesforce instance risked becoming a drag on the organization — pushed to support tactical functions and processes that were not a good fit to its core purpose.

As a result, the goal, as Salomon describes it, was not to replace Salesforce — which remains a key system of record — but to extract unrelated business processes and make them more visible, scalable, and adaptable:

The goal was to extract, piece by piece, the parts that didn’t belong in Salesforce and rebuild them with proper technologies — JavaScript, Go, Python, whatever. Essentially make a service, expose APIs, and work asynchronously as much as possible with events.

But a bias towards action — and a few mind-blowingly complicated meetings about processes — ultimately pushed Salomon away from traditional implementation and towards a more experimental posture.

Building momentum through concrete action

Less than two weeks into his new role, Salomon says he found himself immersed in detailed discussions about the company’s operations:

During my first meetings, there were gigantic business processes being described. I was listening and trying to understand the specifics of the operating model and the problems I had to tackle, but it seemed huge.

To avoid getting stuck in analysis, Salomon says he began to look for specific process issues he could tackle quickly — and tools he could use to build early momentum:

When I first joined the company, I didn’t know Salesforce — I’m an engineer who codes. But I had previously used the Make platform — and so while listening, I checked whether Make could connect to Salesforce.

Salomon explains that finding Make’s Salesforce connector changed how he approached the conversation with his new colleagues — rather than creating a project plan or formal specification, he proposed to build something:

I pulled aside a technical engineer and a business owner — and gathered around a screen we built a scenario. The project was supposed to take two months — but within one hour, we had something that worked.

Although this felt like a radical approach to his colleagues, the speed of the initial implementation created a ‘wow moment’ for management — something he says established his credibility and won him the freedom to move faster:

Everyone knows that engineers are expensive — and so I knew I had to create value quickly. But this ‘wow effect’ worked and so the management said, ‘Okay, take the lead and show us what you can do’.

With this clear mandate in hand, Salomon says he was keen to press ahead. But his ‘radical proposal’ hadn’t only surprised his business colleagues — it had also horrified his engineering team, as he explains:

I had an issue with my team around adoption. People said, ‘Why use Make? You’re a senior coder!’ I told them, ‘I did this without knowing your technology, in one hour. So let’s not argue about beliefs — whether low code is right or wrong. If there’s an opportunity to do better using Make, then we use it.’

Salomon frames his perspective as practical rather than ideological — simply focused on applying the right tool to the right job.

But as enthusiasm spread across the business, it also triggered a new and more serious problem. One Salomon says had little to do with whether Make worked — and everything to do with the organizational consequences of the fact that it did.

Choreographing change as complexity escalates

As Make spread beyond its initial use cases, Salomon saw adoption growing in a way that was both encouraging and unsettling.

What began as a local capability was enthusiastically adopted by teams across the business — but with very different levels of technical understanding. As Salomon recalls:

We went from one active user to three, to 20, to 50. Every top manager had an account. We created teams for the UK, Belgium, Italy, Spain. They were all trying to build their own scenarios.

At that point, he argues, the speed and agility benefits of democratizing access to technology began to be outweighed by the chaos and risk of uncontrolled change — a shift brought sharply into focus by a sudden poolside interruption:

While I was on vacation, someone modified a scenario and increased its resource consumption by 100x. While I was able to modify the scenario on my phone, that was the trigger for change.

According to Salomon, this incident was the moment he realized that Make had moved from useful tool to critical infrastructure — creating an urgent need to reframe his thinking:

At that time, we were just about to ask for more money to buy more operations. After that incident, I said — we don’t need thousands of transactions. We need millions.

But buying more capacity, Salomon says, turned out to be the easy part.

Instead, Salomon argues that the real challenge was introducing a new approach to governance — one that took account of the differing skills, perspectives, and locations of his newly empowered ‘developers’. He explains:

In conventional coding, I don’t trust my team not to break production. It happens. We don’t pretend it won’t — we prepare for when it happens. We have rollback, we have monitoring. To open Make to non-engineers, I needed to be sure that when I give it to John or Jane — without engineering background, without understanding infinite loops or conditions — I can sleep quietly on Saturday and take care of my kids.

His initial response was to set up a centralized team to take care of all changes — but he recalls that this quickly proved counterproductive and led to significant frustration from his newly empowered audience:

At first, everything had to go through us. But we quickly discovered that this has two unacceptable downsides — it doesn’t scale and it kills innovation.

As a result, Salomon says that he completely reworked his processes to maximize decentralization and autonomy without compromising safety — starting with tighter control over who could deploy different kinds of change:

If our users build something that follows best practice and doesn’t touch critical platforms then we let it live in their team. But only a ‘production’ team can control connections to core systems.

Salomon goes on to explain that the other side of this coin is operational accountability — effectively ensuring clear responsibility for dealing with issues after a team deploys its solution:

Scenarios were augmented with custom properties such as owner and status to ensure accountability. And then I built a ‘meta’ scenario to watch scenarios. Every minute, it checks changes, identifies issues, assigns responsibility, and sends Slack alerts. If an issue is not reviewed by the accountable team, the scenario is shut down.

It sounds brutal but Salomon argues that it acts as a forcing function, not only encouraging teams to take accountability for their scenarios but also increasing the care with which they build them — effectively laying down a framework for decentralized trust.

A topic that took a surprisingly philosophical turn as the conversation widened to questions of portfolio management.

Turning the business into a navigable system

With Make embedded into day-to-day operations, Salomon says he was able to shift his focus from the tactical to the strategic.

In particular, he says his attention moved from narrow operational oversight to the wider issue of portfolio oversight — including the identification of unnecessary duplication, conflict, or cost. But to support this shift in focus, Salomon realized he needed a way to understand the entire landscape — one which matched his way of thinking:

There are two kinds of people — list people and map people. I’m a map person. I need to see where things are, not just have lists that say what they are.

Because of this preference, Salomon says that Make’s ‘Grid’ capability — which generates a real-time ‘city view’ of the automation landscape — has become a critical tool for him:

That’s why I use the Grid as a navigation system. I can zoom out, see all systems, all teams, see markers for issues, see what’s using Salesforce, and access information about scenarios directly.

Equally importantly, Salomon discovered that the ability to see the landscape also made it possible to simplify it — by spotting duplication and eliminating unnecessary complexity. He says:

You see flows visually and realize ‘Ah, we’re doing this twice — we can simplify.’

This focus on visualization directly responds to a common problem in business architecture. While lists can tell you what you have, maps are needed to help an organization understand the spatial positioning and relationships between its systems.

Salomon’s approach represents an interesting implementation of these ideas — and so I ask what major principle he’s used to make it work. His answer is immediate and surprising — naming:

If things are not named properly, you don’t know what they do. You can’t debug them. You can’t monitor them. Naming is not cosmetic — it’s foundational.

This point is clearly important to Salomon — and also feels like one of the most important as our discussion shifts from rapid implementation to strategic portfolio management.

Because Salomon is no longer just describing workflow automation. Instead he’s describing the kind of philosophical infrastructure I’ve talked about in the past — one which captures a common language, an organic view of relationships, and a way to reason about what the organization knows.

Looking ahead, Salomon believes that this investment in enforced naming hygiene — in effectively building a clean ontology — will be even more important as he expands beyond low code automation to embrace AI agents:

As agents scale, it will become impossible to monitor everything manually — we’ll need AI. But if things are badly named, AI will misunderstand or act incorrectly. Philosophy starts with naming. So if naming is wrong at creation time, everything breaks later. You can’t fix naming issues later with more tooling.

An issue that CEOs would do well to keep in mind as they look to make their technology estates understandable and navigable — not just for people, but increasingly for AI.

My take

I should probably have expected that a conversation with a Frenchman would drift into philosophy and the deeper nature of things.

But it was still surprising how quickly a discussion about low code — already rich in lessons about kick-starting transformation in a fast-scaling company — evolved into a deeper exploration of empowerment, governance, and portfolio management in a world of democratized technology.

And what struck me most was how concretely Salomon articulated his philosophical perspective — not through abstraction, but through implementation choices. Naming, for him, is the foundation for scale. Grid provides a way of seeing how systems cluster and relate. And by zooming out across the landscape, he can reason about purpose and alignment rather than individual workflows.

Salomon’s insistence on visibility, ownership, and naming is not a theoretical argument about elegance, but a practical response to the pressures of scaling — pressures that will only intensify as agents introduce an entirely new class of technology asset into the enterprise landscape.

Because AI will not only introduce additional scale and complexity — it will also accelerate existing problems. Where systems are poorly named, weakly understood, or badly governed, AI will not be a solution — it will simply amplify those weaknesses.

Seen this way, the philosophical turn in the conversation feels less like an indulgence and more like a necessity. As Salomon’s experience shows, visibility, ownership, and naming are no longer abstract concerns — but instead represent critical foundations for sustainable operations in the emerging digital era.