CASE STUDIES

Seven systems, and what they make impossible

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.

Client engagements and a co-founded product

SFCTCV

Sector: healthcare · Period: since 2024 · Role: design and development of the front-end; informing the server architecture · Status: engagement ongoing

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 →

Dalya

Sector: software publishing · Period: 2023 · Role: front-end, and a contribution to the AI-assisted feature · Status: team product, engagement completed

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 →

Shareadesk

Sector: real estate · Period: November 2021 – September 2023 · Role: co-founder, design and development of the system · Status: service discontinued

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 →

Crealead

Sector: business services · Role: upstream design, prototype and visual language · Status: engagement completed, no code delivered

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 →

Method lab

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.

Personal lab. No users other than me.

Plume — holding AI agents to written rules on a codebase

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.

Rules, not advice.

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.

A checks file that refuses deviations.

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.

Five files regenerated and compared on every verification.

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.

THE GUIDING PRINCIPLE
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.

Personal research project. No published release.

Latitudes — an app whose ordinary day owes nothing to the network

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.

A network quarantine, named file by file.

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.

Two independent locks, rather than one.

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.

A single language package, born of a specific incident.

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.

What is not locked

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.

THE GUIDING PRINCIPLE
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.

Personal test bench. Never opened to the public.

CornerZ — keeping a record right when three sources disagree

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.

Adjudication screen between several diverging automatic sources.

The machine does not overwrite a person.

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.

Divergence is an object, not an error.

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 adjudication screen is the product.

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.

THE GUIDING PRINCIPLE
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.

L’ÉCHELLE
  • Diagnostic — 1 hour, by video, €200 excl. VAT
  • Audit — 3 days, €2,400 excl. VAT
  • Guardrails — 5 days, €4,000 excl. VAT
  • Architecture engagement — per day, €800 excl. VAT / day

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.