Address
Utrecht, Veenendaal
Work Hours
Monday to Friday: 9am to 5pm
Weekend: 10am to 5pm
a.s.r. needed a new identity applied across its corporate platform, and the obstacle was the component layer underneath it. I restructured that layer first, covered it with automated tests, and then rolled the change out across a live commercial platform.
- Clienta.s.r., one of the largest insurers in the Netherlands
- Period2024 to 2026
- RoleFreelance full stack engineer
- TeamScrum team of 7 developers, 9 people in total
- Coordinated withMarketing and IT, around the release calendar
- A component layer restructured so a platform wide change is made once, not in dozens of places.
- Automated tests around everything the restructure touched, so a change could not quietly break behaviour.
- Rolled out across a live commercial platform without disrupting a single running campaign.
Context
The a.s.r. corporate platform is a live commercial site with campaigns running on it. Its component layer had grown over years without a consistent structure, so a change that should have been made once had to be made in dozens of places, and there was no test coverage to say whether any of those changes had broken behaviour.
The challenge
Rolling anything out across a live commercial platform is a scheduling problem before it is an engineering one. Marketing had campaigns in flight and IT had releases planned, and neither was going to pause. So the work had to be sequenced against a release calendar that already existed, and every change had to be provably safe before it went anywhere near it.
What I did
- Restructured the component layer, so a platform wide change is expressed once and stays maintainable afterwards, which is the difference between applying an identity and applying it again next year.
- Put automated tests around everything being touched, in Playwright, so a restructure could not silently change behaviour on a page nobody thought to open.
- Did the code quality work the restructure surfaced, rather than routing around it, because that is what makes the second change cheaper than the first.
- Sequenced the rollout against the release calendar, and agreed with marketing and IT what was changing when, in both directions.
- Applied the new identity on top of that structure, consistently, which was only possible because the structure came first.
The outcome
- The new identity went on consistently, because the structure underneath it could carry it.
- A component layer that came out of the project more maintainable than it went in.
- Test coverage where there had been none, on the areas that carry the most change.
Technologies used
- .NET: Backend services behind the corporate platform.
- 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: The release path the rollout was sequenced through.
- TypeScript: The language across the component layer.
- Sitecore: The CMS managing content across the site.
- Vue.js: The component layer that was restructured and covered with tests.
- Playwright: Automated coverage around the areas being changed.
- SCRUM: How the work was planned and delivered.
Restructuring a component layer under live traffic is mostly sequencing, and I will happily talk through how I plan one.