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.
Sector: healthcare
Period: since 2024
Role: design and development of the front-end; informing the server architecture
Status: engagement ongoing
The context
A learned society keeps its discipline alive through its congresses. Surgeons register, choose options and a hotel room, pay, and above all submit scientific abstracts that their peers score before selection.
Each of these objects carries a concern of its own, and they are not alike. A registration is a financial commitment. A hotel booking commits a third party. An unpublished abstract is confidential information belonging to its author. And peer scoring is worth nothing unless nobody can see what they must not see. Building this application is not assembling registration screens: it is making four confidentiality regimes coexist in one product, in front of an audience with no tolerance for approximation and very good reasons to have none.
The system lives in two code repositories, one maintainer each. I am the sole human author of the 776 changes recorded on the front-end since March 2024 — a figure as at 5 September 2026. The server belongs to a senior back-end developer: we design the features in tandem, and I inform his architecture choices without writing the code.
The scope, stated precisely
I designed and developed the front-end. I informed the architecture choices on the server without writing its code. The design of the features was done in tandem with the senior back-end developer who authored it.
This distinction is not a drafting precaution, it is an exact description of the work. Deciding what a server must guarantee, writing it down, and letting someone else build it requires being able to phrase a constraint without imposing an implementation — and accepting that you will be judged on the constraint rather than on the code. It is also what allows an architecture to outlive whoever set it.
The decisions
Specify the server from the front-end, before it knows how to answer.
A scheduling feature called on the server for a capability it did not yet have. The usual reaction is to wait, or to improvise on the front-end while promising to clean up later; both are paid for, the first in calendar time, the second in debt.
I wrote the specification for it: what the server must return, the option I was setting aside — a simple flag placed on existing events, which would have weighed down every request already in place — and the reason for setting it aside. Recording the rejected option with its rationale is not documentation for comfort: a choice of which only the outcome was kept is no longer a choice six months later, it is a convention nobody dares question because nobody remembers what it cost.
In the meantime, the front-end queries the server on load. As long as it does not know this function, the feature stays hidden without leaving a hole in the screen, and it will switch itself on the day the server publishes it. The concrete consequence: no release to synchronise between the two repositories, and therefore no window in which one ships halfway while waiting for the other. That is what lets two repositories held by two maintainers each stay coherent.
Treat a paid licence as a verification, never as a declaration.
The table, chart and calendar components are under commercial contract. A key that fell outside its validity window has already put an “expired licence” banner over the interface. That is not a technical failure: it is an unpaid-bill banner placed over a healthcare application, which the client bears in place of their supplier.
Those components are now pinned to the exact version, and installation is refused if what is installed does not match what is recorded. Alongside, a written list records the permitted licences — thirteen — the forbidden licences — twelve — and thirty-two exceptions, each with a reason and a date. A script checks it and fails on the slightest discrepancy.
The dated exception deserves a pause. An exception without a date is a door left open permanently for a reason since forgotten. With its date and its rationale, it becomes a decision that can be re-examined, and on the day it is re-examined, you know what you had accepted.
Make a channel incapable of carrying health data.
When an error occurs in an application, the browser automatically sends a report to an outside service so it can be fixed. By default, those reports happily carry the identity of the logged-in person and the contents of their screen. It is a leak channel that does not look like a leak channel: nobody inspects it, because nobody thinks of it as a feature.
Here, reports leave without a session identifier, reduced to five indicators. No name, no email address, no medical data, no access token appears in them. You lose a little diagnostic comfort; you gain the assurance that this channel cannot carry what it must not carry, independently of what someone adds to it next year.
A second point, more ordinary and more frequent: bulk sends from the delegate tables put recipients in blind copy. The ordinary leak is not an intrusion, it is a list of participants in the clear inside a message somebody forwards.
What is not locked
Pinning component versions is automatic: it applies before every release, without anyone having to think about it. Checking the licence list, by contrast, is run on demand. These are not two guarantees of the same nature, and I do not present them as such. As long as that check is not triggered on every proposed code change, a dependency under a forbidden licence can get in with nothing opposing it at the time. It is written here because it is true, and because it is exactly the kind of discrepancy an audit should produce: not “there is a problem”, but “here is the rule, here is where the machine holds it, here is where it still rests on a person”.
THE GUIDING PRINCIPLE
I work on the assumption that I can forget. What protects a patient or a contract is therefore placed where forgetting is refused by the machine, rather than where it gets noticed after the fact.
The stack
React, TypeScript, Vite, Redux Toolkit and RTK Query, MUI and MUI X Premium, Sentry, Vitest, GitHub Actions, in front of a Django REST API on PostgreSQL held by my counterpart.
What the client says
« He took ownership of our challenges with discernment […] all while anticipating our needs and proposing well-informed solutions. »
— Managing Director, SFCTCV
« Excellent skills in web development, architecture and AI. He brings a genuine product vision centred on UX. »
— Renaud D., senior back-end developer on the project
L’ÉTAPE SUIVANTE
If your situation resembles this one — a system in service, business rules that must hold, and the need to know which ones actually hold today — the three-day audit is the answer. It says where you stand, in what order to act, and what each postponement costs; the repair work comes afterwards.
AI-generated codebase audit: what holds, what has to be redone — 3 days, €2,400 excl. VAT
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
