The team behind the platform
Teams own their work from the first conversation through to running it in production. We practise DevOps and agile, and the Gyshido approach of working out what matters and getting it done is how we think, day to day.
How we work
You own whole problems and choose how to solve them.
Go and TypeScript, running on Kubernetes in GCP.
There is an office in Amsterdam, with no attendance requirements.
Few management layers, so decisions stay close to the work.
The platform powers EV charging across Europe, handling tens of thousands of charging messages a minute and settling energy across borders every day. What you build runs against that volume straight away.
Technology principles
Uptime and correctness are planned and prioritised alongside features, in one backlog.
Whoever builds a service also operates it, carries the pager for it and decides how it changes. There is no separate team to hand problems to once the code is written.
On the path that moves energy and money we use proven, well-understood technology. We keep experiments off that path.
Changes go out behind flags as they merge, often several times a day. Smaller releases make a problem easier to spot and quicker to undo.
The platform speaks OCPP and OCPI, the protocols the industry shares. Any compliant network can connect, and customers stay free to leave.
Every service emits metrics and traces through Prometheus and OpenTelemetry into Grafana and SigNoz. When performance or reliability is in question, we have the numbers to answer it.
From a conversation to the next iteration
Most work begins with a customer, an operator or another team describing a problem. Developers join those conversations early, while the problem is still being worked out.
We write down the problem, what a good outcome looks like, and the constraints, before choosing a solution.
The team breaks the work into pieces it can ship and reason about, sizes them, and decides what to leave out for now. Plans change as we learn more.
Work ships in small increments behind flags, and the people who raised the problem can try it early. Feedback tends to arrive while the work is still easy to change.
We watch how a change behaves in production, keep refining it, and retire it when it stops paying off.
We use AI to turn customer conversations into requirements: it captures what was said, flags the gaps, and puts everything in a common format, so we spend less time on routine writing.
We expect developers to notice problems and opportunities, make the case for them and see the good ones through to delivery. The person who raises something is usually the one who carries it.