I Built a Desktop, Not a Portfolio

This site did not begin as a branding exercise. It began as a refusal.

I wanted a personal site, but I did not want the operating model that usually comes with one: a WordPress install, a database, a login surface, themes, plugins, update drift, and the quiet background anxiety of knowing there is always one more thing to patch. I did not want my personal writing and portfolio to sit on top of an attack surface that had nothing to do with the work itself.

So the first version of this project was not “a creative portfolio.” It was a self-programmed alternative to WordPress. The original goal was simple: keep the publishing workflow, remove the unnecessary surface area, and own the entire stack.

Why replace WordPress at all?

WordPress is useful for a lot of people. It solves real problems. But for my use case, it solved the wrong ones and introduced new ones I did not want to carry.

As an engineer, I care about the relationship between complexity and maintenance. A site becomes expensive long before money enters the conversation. It becomes expensive when every small change depends on too many moving parts. It becomes expensive when content is trapped behind an admin surface. It becomes expensive when presentation and infrastructure are tied together so tightly that even writing a post feels like operating a product.

The old site did what I needed at the time, but it stopped feeling defensible. I wanted:

• static output instead of a live CMS runtime
• text files instead of dashboard-managed content
• version control instead of admin history
• direct ownership over layout, motion, and interaction
• a blog that reads like an archive, not a theme demo

That pushed me toward the current stack.

The stack I actually wanted

The site now runs on a static-first stack built around:

const stack = ["Astro", "React", "TypeScript", "Bun", "Markdown", "MDX"];

That combination matters more than it may look.

Astro gives me a static-first architecture, which means most of the site ships as plain HTML and CSS instead of a permanently hydrated JavaScript application. That is a strong default for a personal site. It keeps the site fast, keeps deployment simple, and keeps the operational model boring in the best possible way.

React is used where interaction actually earns its place: the desktop shell, routed transitions, window behavior, and the portfolio surfaces that need state. I did not want to pretend everything is a pure document when parts of the experience are clearly application-like.

TypeScript gives the project a spine. Once a site grows beyond a few pages, content models, frontmatter, UI state, and route behavior need structure. TypeScript helps keep that structure honest.

Bun keeps package management and scripts fast enough that iteration feels lightweight.

Markdown and MDX bring the most important part back to where it belongs: text. Posts live as files, not database rows. They can be diffed, reviewed, edited locally, and migrated without ceremony. That alone makes the system feel calmer.

In other words, I replaced a CMS with a codebase, but not because code is inherently better. I did it because in this case the codebase is easier to reason about than the CMS.

Why a mock desktop?

The technical rewrite could have ended in a normal portfolio. It did not, because “normal portfolio” was precisely the problem.

I did not want a generic hero section, a grid of cards, a stock gradient, and three lines about passion and innovation. That style of site may be acceptable, but it is interchangeable. It says nothing about how the owner actually thinks.

The desktop metaphor changed that.

A desktop is a working surface. It implies tools, folders, routes, experiments, clutter, intent, and habits. That was much closer to the truth of what I wanted the site to communicate. I wanted the homepage to feel like an operating environment, not a brochure. I wanted the portfolio to feel like opening a focused application. I wanted the blog to feel like an archive you step into from the same machine.

At some point the site stopped being “my alternative to WordPress” and became something more useful: a reflection of my mental model.

That is the part I value most.

The mock OS shell gave me room to express taste that ordinary templates flatten away:

• the glassy, Windows 11-inspired surfaces
• the route transitions that feel like opening software rather than loading pages
• the separation between desktop, portfolio, and blog while keeping them in one coherent world
• the sense that the site is not only presenting work, but preserving a journey

That last point matters. This is where I store the story of what I have been building and learning: HTB-related apps, portfolio case studies, design experiments, blog essays, lab notes, and the general trail of becoming better at the craft.

What makes a site expensive?

People often look at a polished website and assume the value comes from code volume. That is almost never true.

What makes a site expensive is not the HTML. It is the judgment.

Good websites cost money because they compress a large number of difficult decisions:

• what the site is actually trying to say
• what to remove so the signal is clear
• how to structure information so it feels effortless
• how to make motion feel integrated instead of decorative
• how to tune spacing, typography, contrast, hierarchy, and pacing
• how to make something feel custom without becoming chaotic
• how to keep it fast, accessible, and maintainable while still making it memorable

That is where the thousands of dollars usually go. Not into the privilege of having code written, but into having taste applied consistently.

That is also why cheap websites so often look cheap. They are not merely underbuilt. They are under-decided.

Where Codex changed the equation

One of the most interesting parts of this project is that a large amount of the implementation work was done with Codex, on a twenty-dollar subscription.

That sentence sounds like a punchline until you understand the real tradeoff.

Codex did not magically invent the site. It did not provide taste by default. It did not know what should feel editorial, what should feel like software, or why the homepage should remain a desktop while /portfolio/ becomes a cinematic routed experience and /blog/ becomes a premium archive.

What it did provide was leverage.

It made iteration cheaper. It made refactoring faster. It made it practical to test multiple directions, preserve the ones with character, and discard the ones that felt generic. It allowed me to treat implementation as a conversation instead of a queue of expensive manual labor.

That is the real value.

If a site like this might reasonably cost at least a thousand dollars in traditional delivery terms, the interesting part is not “AI made it free.” The interesting part is that the cost structure changed. A person with strong taste, clear constraints, and enough engineering judgment can now reach outcomes that previously required far more budget, time, or coordination.

In that sense, Codex did for site-building what good tooling always does: it moved effort away from repetitive execution and toward decisions.

And decisions are the part I actually care about.

The philosophy behind each step

Every major choice in this project came from the same engineering instinct: reduce accidental complexity, keep intentional complexity.

I removed WordPress because the attack surface was accidental complexity.

I chose text-backed content because writing should remain portable.

I chose Astro because static output is the right default for a personal site.

I kept React where the interface genuinely behaves like software.

I leaned into the desktop metaphor because it carried meaning, not just styling.

I kept /blog/ and /portfolio/ as separate routes because they deserve their own pace, but held them inside the same visual world so the site still feels like one machine.

And I kept iterating until the result no longer looked like “a portfolio built with tools” and started looking like “a place that could only belong to me.”

That is the standard I was after from the start, even before I had the right words for it.

Closing Notes

This site is still a work in progress, but it now rests on foundations I trust more: a smaller attack surface, a cleaner publishing model, a stronger design language, and a structure that can keep absorbing new chapters of my work.

I did not set out to build a mock desktop for novelty. I built it because it became the most honest way to represent how I work, what I value, and how I want my corner of the web to feel.