Building this portfolio as a quiet system

I did not want this portfolio to behave like a brochure that gets redesigned once, published, and then slowly forgotten. I wanted it to feel like a small working system: easy to update, honest about what I build, and calm enough to keep using.

Why rebuild it

The first job of a portfolio is simple: give a fast signal. In a few seconds, someone should understand who I am, what kind of work I do, and where the proof lives.

The harder job is maintenance. A portfolio changes every time a project ships, an experiment becomes useful, an article is written, or a contact detail moves. If those updates require touching layout code every time, the site starts fighting its own purpose.

That is why this version is static, but content-driven. The interface is built with Astro. The writing lives in Markdown. The pages are generated at build time and deployed to GitHub Pages.

The goal is not to make the site complicated. The goal is to make future changes boring.

The architecture rule

The rule I am following is small but useful:

• Markdown owns meaning
• Astro components own structure
• CSS files own presentation
• utility functions own routing, dates, and localization

This split keeps the codebase readable. If I want to update a project summary, I edit content. If I want to improve how project cards look, I edit a component and its CSS. If I want to add a new language, the content tree already has a place for it.

It is not a big architecture. It is a quiet one.

Layer	Owns	Why it matters
Markdown	Writing, project data, localized content	I can update the site without touching layout code.
Astro	Routing, rendering, collections	The build turns content into fast static pages.
CSS	Spacing, typography, interaction states	Visual changes stay near the component they affect.
GitHub Pages	Hosting	The deployment stays simple and predictable.

What the homepage should do

The homepage is designed as a signal, not a pitch deck. It should quickly answer three questions:

• What does Elsy build?
• What proof can I inspect?
• What is the next useful page?

That is why the page stays compact. The ASCII avatar gives the site a personal mark. The work section shows a few projects instead of everything. The experience section gives context. The contact section makes the next step obvious.

home
├─ signal: who I am
├─ proof: selected work
├─ context: experience
└─ next step: contact

What the log should become

The log is not meant to be a fake changelog. It is the place where the portfolio can breathe.

Some posts will be technical notes. Some will explain decisions behind projects. Some will document experiments, mistakes, and small lessons. The important thing is that each post should have a reason to exist.

If the work page is proof, the log is the thinking trail behind the proof.

The part I like most

This setup is modest, but it fits the way I want to work. I can write a Markdown file, commit it, build the site, and publish without adding a backend or opening a CMS.

That keeps the site close to Git, close to the code, and close to the actual work. For now, that is exactly the right amount of system.