The blogBrick by brick · Episode 4/5
Published on
The only project that had users
Twenty months, five applications, and the discovery that what people adopt is never what took longest to build.
"Brick by brick" series, Episode 4/5 · 1. The code Auditor · 2. Documented search · 3. The FHIR bridge · 5. The model is the last question
A brick laid before the others
Let's start with a confession about chronology.
This brick isn't the last one laid. It's the first. It runs from September 2024 to April 2026, well before the code Auditor, well before the medical demonstrators. If it comes fourth in this series, it's because it explains the other three: the questions I asked myself afterwards, alone in front of a screen, were all born here, in front of people.
Twenty months on an apprenticeship contract with a media and B2B marketing company, working directly with the executive team. Five applications, from first experiments through to tools that teams open in the morning. And one thing that no demonstrator, no GitHub repository and no blog post can teach you: what happens when somebody other than you has to use it.
What I brought wasn't technical
Before AI, I was an internal controller, then a bank inspector. A job whose core consists of walking into a department you don't know, working out in a few days how the work actually gets done there, and spotting the gap between the written procedure and the practice.
I thought I'd changed profession. In fact I kept the first gesture and changed tools.
Because the first phase of an AI project isn't development. It's a process audit that doesn't say its name. How is this work done today, step by step? Who produces what, from which information, and in what form? What already exists in the applications in production, and why does nobody use it? Where are the inconsistencies between what I'm told in the meeting and what I see on the screen?
An inspector asks those questions by reflex. They did more for these projects than any architectural decision.
And they aren't asked once, in a specification signed at kickoff. They're asked again at every iteration. Development adjusted conversation after conversation - by showing, listening to the objection, coming back. What users actually needed was almost never what was stated at the first meeting; not out of bad faith, but because we describe badly what we do every day without thinking about it.
I remember the exact moment I knew the method was working.
On one of the applications, I'd run interviews for weeks: several people, several departments, the same question asked from different angles until the real process took shape. Then came the time to have the tool tested. The person designated as pilot opens it, uses it for a few minutes, and remarks, amused:
"That's funny, this is exactly what we do."
She said it the way you note a coincidence. I took it as the best feedback available.
Because that's precisely what you're after. Not "this is impressive", not "I'd never have thought AI could do that" - those sentences are pleasant and predict nothing. But "this is what we do" means there'll be nothing to explain, nothing to relearn, no procedure to rewrite. The tool slots into the work instead of asking the work to slot into the tool.
That sentence wasn't a coincidence. It was the product of every conversation that had preceded it.
The lesson that surprised me most
Here's the finding I wasn't expecting, and which changed how I work.
The applications adopted fastest weren't the ones I'd spent the most time on.
No correlation. None. Some cost me weeks of design, fine adjustment, care over details - and stayed lukewarm. Others, simpler, found their audience in days.
What the second group had in common is disarmingly banal: they dealt with a tedious task. Not an important task, not a strategic one. A task people hate doing.
Generating content from PDFs, or from recordings made as a matter of routine, for instance. Nobody needed that application sold to them. The time saved was immediate, visible, and above all it landed on the kind of work nobody asks for when they arrive in the morning. Adoption required no persuasion. It required the tool to exist.
There's a second family of successes, rarer and more satisfying: the application that does what no other resource can. Not faster - better. More precise, better results, on a need where the existing options disappointed. That one was adopted quickly too, and for a different reason: it wasn't replacing work, it was making something possible that hadn't been.
Take the rule away with you, it applies to your own trade-offs: you don't buy adoption with development effort. You get it by aiming well. The time you spend choosing the use case pays better than the time you'll spend polishing it.
The project that taught me most is the one nobody used
This one has to be discussed, because it's the most instructive of the lot.
The idea was excellent on paper: automating the write-up of client briefs. A real need, a time-consuming task, immediate consensus in the meeting. Technically, nothing insurmountable - and indeed, the application was built and deployed. It worked.
It wasn't used. The briefs happened verbally, in conversation, and left no systematic trace. You can't summarise what was never captured: the tool was waiting for raw material the process didn't produce.
That's nobody's fault. It's entirely normal, in fact: those exchanges had always worked that way, and nothing required recording them as long as no tool had a use for them. The raw material didn't exist yet, quite simply because the need for raw material was born with the project.
But the lesson is structural, and I now repeat it at every kickoff: before asking whether an AI can do something, check that the information it needs exists, in a durable and accessible form. The order of those two checks decides several weeks of work.
Note the contrast with the applications that were adopted. They started from PDFs, or from recordings made as a matter of routine. In other words: from raw material already there. That wasn't luck, it was the condition.
It's from that finding that my curiosity about interoperability and exchange formats was born, two years later - the subject of Episode 3. The question "what can this system be plugged into?" isn't a technical question. It's the question that decides whether the project exists.
What remains afterwards
The apprenticeship ended when I graduated, in spring 2026. An ending planned long in advance and known to everyone from day one, which is probably the best possible configuration: you build differently when you know you won't be there to maintain it.
Concretely, that means self-sufficient applications, put in the hands of the teams rather than tethered to their author. The end-of-assignment criterion wasn't "it works", it was "it works without me".
I think that's the only honest definition of success in this job. A system that depends on the presence of the person who built it hasn't been delivered. It's been lent.
Last word
Three demonstrators say what I can build. This one says something else, and that's why it belonged in this series: what I can do when there are people across the table.
Listen to how the work really gets done. Spot the gap between what I'm told and what I observe. Understand an organisation before proposing anything. Accept that a good project can die because its raw material doesn't exist, and say so early rather than late. Aim at tedious tasks before noble ones. Leave with the tool still standing.
None of that is artificial intelligence. It's what decides its fate.
Which brings me to the question I'm always asked at the first meeting: which model to choose. You can probably guess what I think of it by now.
That's Episode 5.
📖 In the same series - Episode 1: the code Auditor (describe quality before producing it) · Episode 2: documented search (an answer that cites its sources, or says nothing) · Episode 3: the FHIR bridge (plugging knowledge into the real world) · Episode 5: the model is the last question (the four questions for the first meeting).
The three systems described in this series are online and public. I design traceable, verifiable AI systems, from use case to deployment - more about my background, or write to contact@lamoulinette.ai.