Address
Utrecht, Veenendaal
Work Hours
Monday to Friday: 9am to 5pm
Weekend: 10am to 5pm
New coverage functionality on the a.s.r. insurance platform, delivered to a launch date set outside engineering and across APIs owned by other teams. I lead the track, which is the planning and the alignment as much as the building.
- Clienta.s.r., one of the largest insurers in the Netherlands
- Period2026
- RoleFreelance full stack engineer, leading the track
- TeamScrum team of 7 developers, 9 people in total
- ConstraintA fixed date, and APIs owned by other teams
- Led from the planning with the project manager through to delivery, not handed a plan and asked to build it.
- The dependencies sit with other teams, so the schedule is a negotiation before it is a plan.
- Split so value lands early, which keeps the release batches small and gives the business something to look at before the date.
Context
New insurance coverage is a commercial commitment before it is a backlog item. The date is set and the product is priced, and the platform has to be ready on the day. This track adds that functionality to the same platform the application flow and the calculation tool run on, in the same scrum team of 7 developers and 9 people in total.
The challenge
Almost none of the risk here is in the code. It sits in the parts other teams own: the APIs this functionality reads and writes are theirs, on their roadmaps, against their own commitments. A date you do not control and dependencies you do not own is the combination that turns quietly into a late delivery, and it only stays out of that if somebody asks the uncomfortable question early enough for the answer to be useful.
What I did
- Took the track from planning through to delivery, which on this one means the conversations before the first ticket count for as much as the engineering after it.
- Went high level first, deliberately, and spent the time understanding the whole shape of what was being asked before committing the team to a slice of it.
- Worked the plan with the project manager, carefully and repeatedly, because a date set outside engineering is only credible if the plan behind it is honest about what fits.
- Aligned with the other teams on the API dependencies, what they would expose, when, and what this platform does in the meantime if any of it moves.
- Built it on the platform, in .NET behind the Vue.js flow steps, on the services the application flow and the calculation tool already run on.
- Split the functionality so value lands early, rather than arriving whole at the end, which keeps release batches small and gives stakeholders something real to react to.
The outcome
- Dependencies on other teams agreed rather than assumed, which is where a date like this is usually lost.
- The business can see what lands when, on a plan it helped build.
- Ongoing at the time of writing, which is the honest state of it.
Technologies used
- .NET: The backend services behind the new functionality.
- C#: The language of those services.
- GraphQL: The API layer over the platform.
- API development: The interfaces between this platform and the other teams.
- 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 increments go out through.
- TypeScript: The language across the application layer.
- Vue.js: The user facing steps.
- Playwright: Automated coverage of the flows being extended.
- SCRUM: How the team works, and how the increments are planned.
If your delivery risk sits in other teams roadmaps rather than in your own code, that is the kind of track I am used to leading.