Contents7
At a glance
In thirty seconds- StakeA paid-leave fund pays employees' leave indemnities: every request must reach it complete, quantified and validated, without re-keying.
- MechanismA NestJS API structures leave periods and exchanges files with the existing system over SMB; a Vue 3 interface guides data entry.
- ProofA year of contributions to the API and the interface, from November 2024 to November 2025, and an audit of the application in October 2025.
- ImpactEvery request has an identifiable status and path, and the application fits into the existing file exchanges instead of duplicating them.
- LimitsI contributed within a team of at least five developers; I claim neither the lead nor the overall design.
- Client
CICP2R- My role
- Full-stack developer, contributor
- Setting
- Through a partner
- Team
- Embedded in an existing team · 5 peopleWithin a team of at least five developers.
- Technologies
NestJS- Vue.js
Pinia
TypeScript
- Links
The starting point
CICP2R is a paid-leave fund (caisse de congés payés): a non-profit association founded by employers in 1937, supervised by the French Ministry of Labour, which pays employees their paid-leave indemnities. To pay correctly, it needs every request with its periods, its days to pay and, where relevant, the employee’s departure.
Leave management gathers many small frictions: a request sent through one channel, validated through another, then copied by hand. Each step is simple; chaining them is much less so.
What I built
I worked on the API as well as the interface, within the project team. The application collects requests, structures leave periods and stores them with each request, then puts them through a validation before export.
On the server side, the NestJS API exchanges files with the existing system over SMB: the application fits into the circuit already in place instead of creating a second one. On the interface side, Vue 3 and Pinia carry data entry, the request grid and the leave state.
What the evidence shows
My work shows in the history of both repositories, the API and the interface, over a year1. In October 2025, an audit of the application documented how it actually works2: storage of leave periods, validation circuit, state management in the interface.
Git history: 33 commits on the…
Git history: 33 commits on the API and 60 on the interface, from November 2024 to November 2025. A commit count measures neither effort nor quality.
Audit notes from October 2025: leave…
Audit notes from October 2025: leave periods stored as JSON, validation circuit, a Pinia store dedicated to leave. They are not published because they quote personal data.
The screenshots below come from a local instance of the application, fed with fictional data.
What it changes
Every request has an identifiable status and path, from entry to export. The file exchange with the existing system avoids double entry between the application and the fund.
My takeaway: an HR tool is only useful if it matches the organisation’s real circuit. The technology matters less than getting that circuit right and the quality of the exchanges with the system that pays.
Limits
- My part is that of a contributor: other developers wrote a large share of the interface.
- No usage indicator is available: request volume, number of employers, lead times.
- The exact target of the SMB exchange and the go-live date remain to be confirmed.
- The project documents contain personal data: nothing from them is reused here, and the screenshots use fictional data.
Share and reuse
The link, the plain text and visuals ready for LinkedIn.
