When I took over the Integrations team at iptiQ, too much of the work happened through tools built for engineers.

The team connected motor insurance products with national authority systems. When a case failed, someone had to collect context from logs, Grafana, Swagger, APIs, and Postman before they could understand what happened.

The process worked, but it depended on specialist knowledge. It also consumed too much of the team's time.

I built the first version of Heimdall to give that work a proper interface.

Starting with the Netherlands launch

The first use case came from our Netherlands motor product.

The integration needed to work with RoyData, a system used for no-claims information. Matching a customer to the correct record was not always straightforward.

Heimdall brought the relevant policy details, integration events, and possible matches into one place. It showed why the system suggested a match and let someone make a manual decision when needed.

The same interface supported safety checks, suspension, recovery, and dead-letter queue handling.

For RDW certificate cases, Heimdall translated difficult XML responses into errors and warnings people could understand. When it could not complete an action, it linked to the existing tool with the relevant context already filled in.

The goal was not to hide the system. It was to remove the unnecessary work required to understand it.

Building the first useful version

I built the frontend with React and TypeScript.

I was the team's Engineering Manager, but I kept coding because this problem needed a working product more than another document.

The first release went out with the Netherlands launch in January 2023. Engineers used it first. Product colleagues and customer-service agents followed.

Once the tool became useful, other engineers started contributing to it. That was important. Heimdall could not become another system understood by one person.

Making team knowledge visible

One senior engineer held a large part of the integration knowledge. When he left, the risk became obvious.

The team understood the systems, but much of that understanding lived in conversations, debugging habits, and memory.

Heimdall gave us a place to make those decisions visible.

It showed the current state of a case, the events that led there, the available recovery actions, and the comments around previous decisions.

That helped new people learn the system. It also made it easier for non-engineers to solve cases without waiting for someone from the development team.

The result

The team estimated that Heimdall recovered about 50% of its operational capacity.

That figure was not instrumented, so I do not present it as an exact measurement. It was the team's estimate based on the work that stopped reaching engineers.

The more important change was that operational work became visible and repeatable.

Before Heimdall, a difficult case often started with a message to the person who knew where to look.

After Heimdall, it started with the product.

What I took from it

Internal tools deserve product thinking too.

The users may sit next to you, but they still deal with unclear workflows, missing context, and software that expects them to understand its implementation.

Heimdall worked because it did not start as a dashboard project. It started with a specific question: why does the team spend so much time understanding and recovering the same kinds of failures?

Once that problem was clear, the interface followed.