Three client engagements, one co-founded product, three in-house labs. Every technical claim on these pages was checked against the source code.
Anything that is not code — a date, a competition award, a testimonial — is given as such, with its author.
A portfolio usually shows screens. A screenshot says nothing about what happens when two client companies share a single database, or what the system does at three in the morning when a licence key expires. So these pages show something else: three rules per system, what each one makes impossible, what it leaves uncovered, and who set it.


A learned society for thoracic and cardiovascular surgery. Since 2024 I have designed and developed the front-end of its congress application — what the user has in front of them: registrations, hotel booking, payment, submission and peer scoring of scientific abstracts. The engagement is ongoing.
Read the case study →
Invoicing software for French freelancers and small businesses: quotes, invoices, credit notes, reminders. The challenge fitted on one line — produce an invoice from a sentence written in French, without a text invented by an artificial intelligence becoming a legally false document.
Read the case study →
An entrepreneurial project I co-founded, from November 2021 to September 2023, discontinued since. The challenge: making rules about money and confidentiality hold between strangers.
Read the case study →
An entrepreneurs’ cooperative. An engagement to design its internal portal. The deliverable is a navigable prototype and a visual language, intended to be tested with real members before any development. No application deployed, no code delivered — and that is precisely the point of the engagement.
Read the case study →Three personal projects, which remain laboratories. A practice is offered to a client once it has been built, broken and rebuilt several times on my own systems: what I prove at my own expense is what goes out on engagements.
A long-form writing environment with AI assistance. It is where I work on the question my clients face: letting AI agents contribute to a codebase without its coherence degrading, month after month.
Agents there receive written rules rather than recommendations, each carrying three things: what it forbids, the incident that gave rise to it, and the command that proves it was honoured. A rule without its verification command is a wish.
Five hundred and three lines of checks read the code on every verification. This is not assisted review: it is a refusal. Code that crosses a rule does not move forward.
Produced automatically from the code — including the description of the server interface — they are committed to the repository, then regenerated and compared. The slightest difference stops everything. That is what keeps the documentation from lying without anyone noticing.
What is written in a document gets forgotten. What the machine verifies reminds you on its own.
TypeScript, Node.js, PostgreSQL, AI agents under written constraint.
This is the practice I install on engagements, transposed to your repository and written from your own incidents — the AI guardrails offer.
Its main rule: what the user does there every day should never depend on a connection. A rule that is easy to state, and that gets lost with the first feature added by someone in a hurry.
In the mobile app, one folder alone may speak to the server, and exactly two files may reach it. The list is nominative: not one file more, not one fewer.
That list is held by two checks that know nothing of each other: the tool that reads the code as it is written, and a test that demands exact equality. Why two rather than one? Because a single lock comes off in one discreet edit. Two locks come off in plain sight.
An operating rule does not come from a guide to good practice: it is written after the outage, and phrased so that the same outage can no longer replay unseen.
The decision to keep AI out of the engine that composes the day rests on the structure of the code and on review, not on an automated check. I put that in writing rather than let anyone believe otherwise: not every rule can be made mechanical, and an honest inventory is worth more than an approximate guarantee.
A single lock comes off in one discreet edit. Two locks come off in plain sight.
TypeScript, React Native, Expo, SQLite.
Mechanically unbreachable boundaries and agent documentation are exactly what the AI guardrails offer puts in place.
The subject fits in one sentence: keeping a record right when three automatic sources contradict each other, and a member was there yesterday. It is the problem every aggregated dataset raises — and the one AI makes more frequent, not less.

When an automatic source contradicts a human entry, it does not overwrite it: it opens an adjudication. The hierarchy is set in the code, rather than left to the order in which updates arrive.
Three sources that disagree do not produce a failure: they produce a record marked as disputed, with what each one claims. Silently overwriting in favour of the latest would be the only real bug.
The rest — aggregation, normalisation — is plumbing. What gets designed is the place where a person decides, and what they are shown so they can decide quickly and well.
Aggregated data without explicit adjudication is not data: it is whichever source arrived last.
TypeScript, React Native, Node.js, PostgreSQL.
This is the question an audit takes on when a product consumes several sources: where the boundary runs, and who decides.
The thirty-minute call is free and commits you to nothing. It serves to work out which of these formats answers your situation — or whether none of them does.
We use cookies solely for the site to work properly. With your agreement, we also enable the Calendly scheduling module, which sets its own cookies. You can change your mind at any time from the footer. Learn more