The client and the context
FNTP is the Fédération Nationale des Travaux Publics, the French federation of public works companies. In 2025, we built for it an application that turns the workplace accident statistics of CNAM, the French national health insurance fund, into prevention articles. The product has its own case study.
On the client side, a working group followed the project. It brought together the Federation, prevention bodies and public works companies. Damien, an independent consultant (DM Conseil), ran the engagement with FNTP and had entrusted the development to us.
Before the first day of development, FNTP had already set the delivery date and the schedule of progress meetings, one every two weeks.
The problem
At kickoff, several topics were still open: the output format of the articles, how to publish them, hosting, data storage. The AI agent relied on ellmer and shinychat, two R packages we had never used.
Each presentation of the application to the working group brought new requests. They had to be handled every two weeks without moving the date.
What we did
A status sheet before each meeting. A progress meeting often starts with a long stretch where the vendor recounts what has been done. With a meeting every two weeks and a working group to bring into agreement, we wanted that time to be spent on decisions.
From the first week, we therefore broke the project down into tickets in OpenProject, our project management tool. Before each meeting, Léo Pédemay, our R Shiny developer, drew a one-page sheet from it. The sheet gives the week-by-week schedule, showing what was planned, what was done and what was postponed, then the progress of each work package, the next steps and a section for risks and decisions to be made.
In this screenshot, the names of the project manager and the client contact have been replaced.
Because the sheet arrives before the meeting, its recipient already knows where the project stands when the session starts, and we go straight to the decisions. It is also how bad news arrives early. When the working group’s requests started adding to the scope, the risks section flagged it while there were still seven weeks left to take it into account.
Minutes that answer each request. The working group discovered the application at each meeting, and each demo gave it new ideas. At delivery, about thirty of the 57 features came from these requests. The date was fixed and so was the budget, so each request accepted as is took time away from what was already planned.
For each request, we therefore looked for the need behind it and the least costly way to meet it. The answer went out in writing in the minutes, usually the day after the meeting. It said whether the request would be developed as is, replaced by a simpler solution or kept for a later version. FNTP knew, before the next meeting, what would become of each of its requests.
When the group wanted to display several charts in the same piece of content, we suggested duplicating a piece of content to rework the copy with another chart, a feature much faster to develop. When it wanted to correct an already published article, we presented two options and together chose the simpler one, which is to correct it directly in WordPress, where the editor is more complete.
The discussion sometimes took more than one round. FNTP asked for interactive charts in the published articles, and we explained in the minutes why we would not do it: the application and the transfer of articles to WordPress would have become very slow. Because the Federation cared about it, it asked us to propose something else. We then put the interactivity in the application, with a “Dashboard” tab where the user explores the accident data directly.
The challenge: a storage choice to reopen
Data storage was on our list of questions during scoping. We left that question open at the time, and started developing with PostgreSQL, our usual choice.
It was while developing that we saw a relational database was a poor fit for what the application had to store. A piece of content combines a conversation with the agent, a table, a text and the image of a chart, and the knowledge base is made of PDF documents. The application therefore handles mostly files.
We entered the topic in the risks section of the status sheet before we had a solution, so that the client would know without waiting. We then reviewed the alternatives with the client and what each one risked, for example when two users write at the same time, and the decision was made together. The data is stored in Azure Blob, Microsoft’s file storage service, which the application accesses with the R package AzureStor. The change was completed before delivery.
The results
The scope grew by about thirty features, all completed, and the date did not move. The application was delivered fourteen weeks after kickoff, on the planned day.
The users designated by FNTP had it in their hands from the end of August, which gave them time to test it and send their feedback before delivery.
Nine months later, Damien confirmed to us that the Federation was still using it.
Do you have a project with a fixed date and a scope still open? Get in touch.