Development · Product
This portfolio
The site you are reading: a complete, up-to-date résumé that I can edit by clicking directly on the page.
In short
- Problem
- A one-page résumé does not say everything, and a portfolio often ends up full of skills without examples and numbers without context.
- Solution
- A site that tells the whole story, where every skill is linked to a role or a project, and whose content rules are checked automatically before every update.
- What it brings
- A recruiter finds everything in one place, in French and English, and the content stays reliable update after update.
- Where it stands
- Runs locally and builds without errors, but is not online yet.
- My role
- I wrote the brief, the content rules and the text, and steered the build with Claude Code.
Why this site
A one-page résumé does not say everything. You cut the details, the projects, what you really did in a role. And a portfolio has the opposite problem: it ends up full of skills without examples and numbers without context, because each small shortcut seems reasonable at the time.
I wanted one place where my whole background can be read, in French and English, and stays reliable update after update.
How it is built
Rather than relying on my own discipline, I had the rules checked automatically. A project without a status, a role, evidence or at least one limitation does not get through. A skill must be linked to a role or a project. A number must have its context.
And when something is refused, the message says which file and which field to fix.
Studio mode
While reading the site, I can switch on a Studio mode, click on any block and write what I want to change. The request goes out with the text on screen and the exact place in the content to edit. That is how I improve the site: by reading it the way a recruiter would.
Show technical details
Content kept separate
All the text lives in content files, never in the code. Adding a project requires no change to the site.
Three checks before every update
Content (its shape, both languages being present, the links between skills, projects and roles), sensitive data (keys, passwords, unexpected addresses) and links.
Two languages
Every page exists in French and English. A project published in only one language blocks the update.
Numbers
2
languages
a project published in only one language blocks the update
Source · repository translation parity check
3
checks before every update
content, sensitive data and links
Source · check scripts run before every build
What I did
Needs definition
I wrote a complete brief: who the site is for, what it must show, and what must never be published.
Architecture
I had the content separated from the code, so I can add a project without touching the site.
Rule design
I turned the content rules into automatic checks that block an update.
Assisted development
The interface, both languages and the checks were built with Claude Code.
Documentation
I wrote a guide explaining how to add a project and what the site refuses.
Evidence
Content rules are checked
verifiedA project without a status, a role, evidence or a limitation does not get through. These are not guidelines, they are automatic checks.
- Source
- repository content schema
- Verify with
- Deliberately removed a required field, then saw the update fail.
No number without context
verifiedEvery number has its context and its source. A number that cannot be checked is never presented as proof.
- Source
- repository evidence components
- Verify with
- Read the rules for numbers and how they are displayed.
No sensitive data published
verifiedA check blocks the update if a key, a password, an unexpected address or a path from my computer appears in the content.
- Source
- repository detection script
- Verify with
- Ran the check across all published content.
Limitations
- The site is not online yet: no domain name, no hosting.
- The contact form only appears once a receiving address is set up, which is not the case yet.
- The display is checked by hand, without automated browser tests.
- The checks cover content, not design: nothing prevents a badly designed page.
What I take away
- Writing the rules before the content paid off straight away: the first case studies were rejected by the checks, for real reasons.
- Making a field mandatory, like a project's limitations, forces you to look honestly for what does not work yet.
- Being able to click on a block to request a change makes all the difference: I fix the site while reading it, the way a recruiter would.
What it could bring to a company
- Any team publishing structured content (product sheets, documentation, careers pages) can check its quality rules automatically rather than in a style guide.
- A compliance team can block any publication containing sensitive data in the same way.
Technologies
- Next.js
- TypeScript
- Zod
- MDX
- Tailwind CSS