Burnrazor
Léandre Desmaretz
A site-manifest is not a portfolio with better typography. It is a public system for publishing projects, notes, and technical choices in one readable structure.
Themes: Site Manifests / Editorial Systems / Static Publishing
editorial-systems / positioning / sites
This site did not start from the usual question.
Not "what should my portfolio look like?" Not "what is the cleanest way to present my skills?" Not even "what pages should a personal website have?"
It started from a more annoying question:
Why do so many personal sites reduce real work to cards, logos, and vague claims?
That question mattered because the missing piece was not simply a website. It was a public form capable of carrying the work.
Before this project, what existed online was too thin for the actual range of the work. It did not make it easy to centralize ongoing projects, connect them to notes, or show how technical, editorial, and operational choices relate to one another.
The idea of a site-manifest came from that gap.
Not a louder portfolio. Not a visual CV. Not a content machine dressed up as identity.
Something else: a public system that can hold projects, decisions, notes, and technical choices in one readable structure without flattening them.
Visibility was part of it, but not in the shallow sense.
The issue was not simply "be seen more." It was "be seen more truthfully."
A lot of personal sites are optimized for a first glance that says very little. They can look polished and still fail to communicate anything durable about the person behind them. You learn the stack. You learn the job title. You learn a few categories. You rarely learn the operating logic.
That was exactly the dead end this project had to avoid.
What needed to become public was method as much as output: the way projects are framed, constrained, written, shipped, and connected to a broader body of work.
So the site had to do three things at the same time:
Without that bridge, the site would have become either decorative or abstract.
Projects without notes feel decorative. Notes without projects feel ungrounded.
The useful form is the link between both.
Calling it a portfolio would have pushed the project in the wrong direction from the start.
A portfolio usually implies a few habits I explicitly wanted to avoid:
The manifesto frame changes the center of gravity: the site is not only here to display finished work, but to state a way of building, make choices legible, and let proof accumulate over time.
That changes almost everything:
In other words, the site stops performing confidence and starts exposing structure.
That was the target.
One of the earliest decisions was also one of the most important: the visible navigation would stay minimal.
Home and Blog.
Nothing more in the main public navigation.
That sounds almost trivial until you compare it to the standard personal-site reflex:
About, Uses, Now, Projects, Lab, Speaking, Contact, and a few more weak pages added just because that is what these sites usually do.
The problem with that expansion is not only clutter. It is dilution.
The more pages a personal site adds by reflex, the more likely it is to create weak surfaces. Weak surfaces do not make a site feel generous. They make it feel under-convinced.
So the better move was to keep the public structure dense and clear:
That decision made the site sharper.
The home had to do real work. Projects had to carry weight. Notes had to justify their place.
The most important technical choice in the project happened before a single component mattered: the project started docs-first.
That was not bureaucracy. It was a way to make the concept hard enough to build.
Before real implementation, the project was pushed through:
That layer of documentation did two things.
First, it prevented drift. If the site was going to be a manifesto instead of a generic personal page, every later decision had to stay attached to that intention.
Second, it changed the build process itself. Once the architecture, anti-goals, and hosting constraints were clearly written down, implementation stopped being a sequence of disconnected UI moves. It became a system with explicit rules.
The site feels more deliberate than a lot of fast personal builds because of that early pressure. The public surface may stay compact, but the concept under it was pressure-tested before the interface existed.
The stack was not chosen to sound modern. It was chosen because it matched the shape of the product.
The current foundation is straightforward on purpose:
Each part solves a concrete problem.
The site needed clean support for local content, metadata, route structure, and static generation. Next.js fit that well, especially for a project that needs project pages, article pages, feed generation, sitemap generation, and deterministic metadata without inventing a backend.
The content model could not stay loose. If projects and notes were going to relate to one another cleanly, then metadata, slugs, related content, and content contracts had to stay explicit. TypeScript helps keep those relationships honest.
This was non-negotiable for V1.
The content belongs with the site. It should be versioned with the code. It should stay portable. It should not require a CMS just to publish a project page or refine an essay.
MDX gives the right balance: local ownership, structured metadata, and the option to integrate custom components when the content really benefits from them.
The build chain had to stay simple and fast. Bun keeps the workflow compact. Ultracite with Biome keeps linting and formatting opinionated enough to reduce noise.
Again, sophistication was not the aim. The aim was reducing friction so the system remains easy to keep sharp.
This decision deserves its own section because it is one of the easiest places to drift.
A CMS sounds reasonable very quickly. It sounds scalable. It sounds mature. It sounds like the "real" way to publish.
But for this project, it would have solved the wrong problem.
The site did not need a content admin. It needed editorial coherence.
The practical reason is even simpler: the whole site already moves through local files and Codex CLI.
Writing, rewriting, metadata, structure, internal links, and page-level edits all move faster in that workflow than they would through a CMS. On a site with no products, no image-heavy publishing workflow, and no need for a separate editorial back office, a CMS would mostly add latency.
The V1 corpus is not large enough to justify the complexity of a CMS. The editorial system benefits more from versioned content, explicit registries, and strong local contracts than from a detached interface that turns publishing into form-filling.
The docs-first approach also made the tradeoff clearer: the site is not a newsroom, not a media operation, and not a multi-author publication. It is a precise personal publishing system.
That means the right default is:
The result is leaner, clearer, and easier to reason about.
The site also had to respect a real operational fact: it does not live on an empty machine.
It shares a VM with other production workloads.
That single fact changes the technical conversation. It means the project cannot behave like it owns the server. It means the build path has to stay disciplined. It means runtime surface area should stay small. It means rollback and failure modes matter more than technical theater.
Static generation was therefore not only a nice option. It was the right posture.
The site now benefits from that in several ways:
This also explains why the project produces a real static artifact while still using a controlled Dockerfile path through Coolify. The goal is simplicity of output with explicit control of transport.
Static is the artifact. Controlled deployment is the discipline.
Pretext is one of the most interesting pieces of the stack, but it also had one of the clearest guardrails.
It was never supposed to become the theme.
The temptation with a typographic engine like that is obvious: once you see what it can do, you want to use it everywhere.
That would have been a mistake.
The project needed Pretext to behave like a signature layer. It should improve a few surfaces enough to change perception:
Everywhere else, plain CSS should keep winning.
That restraint protects the visual direction. The goal is not "look how experimental this is." It is closer to clean textual futurism: restrained, precise, typographic, almost ascetic.
Too much typographic machinery would have pushed the whole thing toward spectacle. The site had to feel authored, not theatrical.
Codex deserves to be named because it genuinely changed the speed and shape of the project.
But it needs to be named correctly.
The concept did not come from the tool. The target stack did not come from the tool. The editorial standard did not come from the tool. The product direction did not come from the tool.
Those came first.
What Codex changed was compression.
It became the execution layer I could challenge, redirect, pressure-test, and accelerate across documentation, prototyping, implementation, and rewriting. That compression is especially powerful on a project like this because the site sits in a useful middle ground:
AI-native building becomes genuinely interesting at that point. The distance between idea and implementation collapses. A docs-first concept can move into code faster. A prose change can become a published refinement quickly. A technical exploration can be tested without turning into a month-long detour.
The important point, though, is governance.
Codex changes the slope of execution. It does not replace direction.
That distinction matters more, not less, as these tools become stronger.
Even in its current state, the site is already more than a shell.
Under the public surface, it is doing real structural work:
feed.xml, sitemap.xml, and canonical URLs are part of the system, not afterthoughtsThis is the key shift.
The site is not just presenting content. It is organizing evidence.
That difference is why it reads differently from a generic portfolio. Its job is not to list capabilities. Its job is to make a way of building legible.
One more thing matters here: this site is not being described as finished.
It is live, useful, and already coherent. But it is also a living prototype.
That does not downgrade it. It is part of the point.
The site was designed to stay close to the work as the work changes. That means it should remain revisable:
The right model is not "launch once, freeze, and maintain." The right model is "publish a strong base, then keep it aligned with reality."
That makes more sense for a personal editorial system than pretending the final form is already known.
At the highest level, the site exists to solve a simple but surprisingly stubborn problem:
how do you make a body of work feel coherent in public without reducing it to branding?
This is the answer I currently trust:
build a structure where projects, notes, technical choices, and visual discipline reinforce each other. Keep the public shape minimal. Make the proof denser. Let the writing explain the work. Let the work justify the writing.
That is what a site-manifest means here.
Not a prettier container. A better public system.
At the highest level, the site exists to solve a simple but surprisingly stubborn problem:
how do you make a body of work feel coherent in public without reducing it to branding?
This is the answer I currently trust:
build a structure where projects, notes, technical choices, and visual discipline reinforce each other. Keep the public shape minimal. Make the proof denser. Let the writing explain the work. Let the work justify the writing.
That is what a site-manifest means here.
Not a prettier container. A better public system.
Related projects
Projects stay publicly discoverable through the notes that make the work legible.
2026
active
A public proof of how I build: direction, editorial structure, and technical execution held together in one readable system.
Built as a site-manifest rather than a portfolio, it centralizes ongoing work in a docs-first static system shaped by MDX, targeted Pretext surfaces, and fast iteration with Codex.
Next.js / TypeScript / MDX