How it works
One site, two sides, no database. What follows is how a page gets from the source code to your screen, and which parts of it check themselves.
Two sides, one site
The day side is Cédric Lucchese, developer; the night side is Quyver, producer and DJ. The bar on the edge of the page is a curtain: dragging it reveals the other side live underneath, and releasing past the middle switches over. On a phone it becomes a plain tab.
Every word and every project lives in the source code, in TypeScript modules and two dictionaries, French and English. There are no accounts and no database: nothing a visitor does is stored. Both languages share one URL: your language cookie decides, otherwise your browser’s Accept-Language header.
Pages are rendered on the server (TanStack Start) and arrive as complete HTML: the text is readable before any JavaScript runs.
The work section checks itself
Two sources feed it. The projects written by hand in the code, with their prose in both languages, and the production applications Dokploy (the server’s deployment tool) turns out to be hosting: a project put online appears without a commit. Its text then comes from its Dokploy description.
Before anything is shown, the server sends a HEAD request to every project’s address. Only the ones that answer right now are listed: a hand-written status drifts, and twice it showed as live a project returning an error. A written entry always wins over its discovered twin.
The checks are cached for one minute (five for Dokploy) and refreshed behind the page, so only the first visit after a restart waits. Two safeguards: with no result yet, or with every check failing at once, which points at the server’s own network rather than seven projects dying together, the section falls back to the written statuses. It never renders empty.
The blog publishes by dropping files
A post is two Markdown files, one per language. They are either built into the site, or dropped into a folder on the server that the site reads on every request: publishing is writing the files, with no build and no deploy. A dropped file wins over a bundled one with the same name.
Each release of the site also becomes a card, with the lines of its changelog. Cards are sorted newest first, and a post comes before the release that carried it. The version in the footer leads there.
Readable by machines
Search engines and language models read the same content modules as the page, never a copy written by hand: a schema.org graph describing the person and the work, /llms.txt (the whole site as Markdown, in the language asked for), and /sitemap.xml, where a blog post is listed the moment its files land.
/llms.txt keeps every written project whatever its uptime: a model asking what this person built wants the body of work, not today’s availability. A discovered project that does not answer appears nowhere, neither in the page nor in the files for machines. robots.txt welcomes AI crawlers by name.
Play counts on the night side
The figures next to the tracks come from the official SoundCloud API, read by the server and cached one minute; the public pages refuse server requests. A track that is not on SoundCloud simply has no figure, and without an answer from the API the tracklist shows none. Spotify publishes no stream count anywhere public, which is why only SoundCloud feeds them.
What is not there
No cookie except the one remembering your language. Audience is measured with Umami, self-hosted in the European Union, without cookies, and only on the production domain. Fonts are served by the site itself: no request leaves for Google.
Known limit: since French and English share one URL, search engines only index the version their crawler asks for.