Address
Utrecht, Veenendaal

Work Hours
Monday to Friday: 9am to 5pm
Weekend: 10am to 5pm

a.s.r. Policy Application Flow

The main entry point for every incoming insurance application at one of the largest insurers in the Netherlands. I extended it to dozens more employers, cut the internal errors that were stranding applications, and designed and ran the release process around it.

  • Clienta.s.r., one of the largest insurers in the Netherlands
  • Period2024 to 2026
  • RoleFreelance full stack engineer, and release owner
  • TeamScrum team of 7 developers, 9 people in total
  • ScaleHundreds of thousands of users
  • Extended to support dozens more employers, so thousands more employees can arrange cover through it.
  • Internal errors that were stranding applications part way through, tracked down and fixed.
  • Releases became routine on a process I designed and ran, with stakeholders knowing what was shipping and when.

Context

The application flow and the calculation tool beside it are how a.s.r. takes in new business. Together they are used by hundreds of thousands of people, and the person on the other end of the screen is arranging cover for something that matters to them. Sensitive personal data goes through it at every step. I worked on it in a scrum team of 7 developers, 9 people in total.

The challenge

A multi step application has no forgiving kind of failure. An internal error part way through does not show up as a bug report, it shows up as a person who gave up and did not come back, and neither they nor a.s.r. get anything out of that. Every step also handles sensitive personal information, so security and data correctness are not qualities you balance against delivery speed. They are the floor.

What I did

  • Extended the flow to dozens more employers, which is what lets thousands of additional employees arrange cover through it at all. It opened the flow to customers a.s.r. previously could not serve.
  • Aligned the data and functionality with centralised data inside a.s.r., so the flow reads from the organisation source of truth. That means less maintenance and a closer fit to how the business actually works.
  • Cut the internal errors that stranded applications part way through, so fewer people drop out of a process that is high stakes for them.
  • Extended the calculation tool, to more cover types and more employers, so more employees can work out and arrange their income protection without help.
  • Designed and ran the release process, for the platform end to end, and chaired the ceremonies around it. Releases became routine and stakeholders knew what was shipping and when.
  • Took the functional questions to the stakeholders myself, rather than through a proxy, which is how the ambiguities got settled while they were still cheap.
  • Led the release of the extension itself, a large one, delivered with barely any incidents.

The outcome

  • A flow that reads from the organisation source of truth, which is less to maintain and a closer fit to the business.
  • Fewer applications lost to internal errors part way through.
  • A large release delivered with barely any incidents, on a process that was there for the next one too.

Technologies used

  • .NET: The backend services behind the application flow.
  • C#: The language of those services.
  • GraphQL: The API layer over the platform.
  • Azure: The cloud platform the work is built, released and run on.
  • Azure Pipelines: The deployment pipelines behind the releases.
  • CI/CD: I designed and ran the release path.
  • TypeScript: The language across the application layer.
  • Vue.js: The user facing steps of the flow.
  • Playwright: Automated coverage of the application flow.
  • SCRUM: How the team worked, and the ceremonies I chaired.

This is the work I am doing now, and I am available for a new engagement from 1 January 2027.

Bridging ideas to reality
through elegant code.

Marten Den Heijer