What Wallee shared at AWS Summit Zurich

On 2 September 2026, Wallee took the stage in Breakout 1 at AWS Summit Zurich to share how its team approaches the architecture and operation of an AWS-native platform.

The idea running through the session was simple: build where it makes sense, and own as little as possible everywhere else.

Wallee introduced itself as a Swiss payments platform, native on AWS from day one. The team then walked through several examples of how that principle shapes the platform, including where they choose to build internally and where they use existing solutions.

Build what you need to own

One example was Wallee’s service catalog.

As the team moves workloads from EC2 and ECS towards EKS, the catalog provides a way to keep track of its microservices. The slide described it as something Wallee built in-house, from scratch, with agents.

For Wallee, this is an area where building its own solution gives the team the control and flexibility it needs.

But the same approach does not have to apply to every part of the platform.

A different approach to incidents

Another example looked at incident and maintenance management across the organization, including multiple public status pages.

Here, Wallee showed a different approach. Rather than building and maintaining the entire layer itself, it uses Incido for that capability.

The distinction was part of the broader point of the session. Some components are worth owning because they are closely tied to how Wallee operates. Others are better handled through a dedicated solution.

That lets the team focus its engineering effort where it creates the most value, without taking on the ongoing work of building and maintaining every supporting system.

Own as little as possible

Later in the presentation, Wallee summed up the approach in one line:

Own as little as possible, so that speed survives the complexity.

It is a useful way to look at platform engineering as systems grow. Building something internally can make sense when it provides the control or flexibility a team needs. But owning a component also means owning its maintenance, evolution, integrations, and operational complexity.

Wallee’s examples showed both sides of that decision.

For incident management, maintenance, and public status pages, the team chose a dedicated solution rather than building and maintaining the entire layer in-house. Incido was one example shown during the session.

The focus of the presentation was Wallee’s broader approach to building and operating its platform. It was about deciding deliberately what to build, what to use, and where engineering effort is best spent.