Raghib Hasan

Why I Rebuilt My Developer Portfolio as a Writing Site

The design decisions behind turning raghib.io from an interactive terminal into a clearer home for ideas, experiments, and engineering judgment

Raghib Hasan 4 min read
On this page
  1. What Was Broken
  2. The New Content Model
  3. Designing for Technical Reading
  4. What a Useful Technology Post Should Do
  5. The Technical Changes
  6. The Result

My first version of this site behaved like an interactive terminal. It had slash commands, a typewriter greeting, animated status rings, and a blog styled like filesystem output. It was technically playful, but it created the wrong first question.

Visitors had to work out how the interface operated before they could understand what I did.

That is a poor trade for a writing site. A reader should not need to interpret a terminal metaphor before finding an idea worth considering. Someone looking for an architecture post should not need to discover a hidden command. The presentation had become more memorable than the thinking.

So I rebuilt the site around a simpler rule:

Make the idea clear, then make the evidence easy to inspect.

What Was Broken

The old design optimized for novelty. That produced three practical problems:

  1. Navigation required interpretation. Visitors had to understand that commands such as /writing and /projects were links.
  2. The homepage did not explain the site’s point of view. It introduced a personality, but not the questions, systems, or ideas behind the writing.
  3. Long-form posts inherited the terminal metaphor. Code belongs in a technical article. The entire article does not need to pretend it is code.

None of those issues were implementation failures. They were failures of information architecture.

The New Content Model

The new site has three direct paths:

  • Writing contains essays, technical explorations, and experiments.
  • Projects connects those explanations to working software and source code.
  • About explains the questions and themes behind the site.

The homepage states the intellectual focus and what a reader can expect from the writing. It gives newcomers a useful orientation while letting technical readers move directly into implementation detail.

Designing for Technical Reading

The article layout now treats a post as an engineering document rather than a themed window.

The reading column stays narrow enough to scan comfortably. Metadata is visible but secondary. Headings establish a clear outline, code remains visually distinct, and the table of contents is available without competing with the opening.

The visual system is deliberately small:

  • near-black background;
  • warm white primary text;
  • muted green links;
  • one-pixel dividers;
  • sans-serif body type;
  • monospace reserved for code and technical identifiers.

Removing decoration made hierarchy more important. Spacing, line length, link treatment, and heading rhythm now carry responsibilities that were previously hidden by containers and effects.

What a Useful Technology Post Should Do

The redesign also creates a better default structure for future articles:

  1. Start with a question or problem that matters beyond one organization.
  2. Explain why the existing process fails.
  3. Show the smallest useful architecture.
  4. Keep deterministic systems in control where correctness matters.
  5. Make permissions, policies, and blast radius visible.
  6. Demonstrate the result with real artifacts.
  7. State what changes when the design moves from a small experiment to a production environment.

This structure makes a post useful across contexts. Developers can reproduce the implementation. Leaders can evaluate the operating model. Readers in other industries can separate the enduring idea from the particular tools used to demonstrate it.

The Technical Changes

The underlying publishing stack remains intentionally conventional:

  • Astro statically generates the site.
  • MDX keeps articles close to source control.
  • Shiki handles syntax highlighting during the build.
  • A curated project snapshot keeps the projects page available without a runtime API.
  • RSS provides a platform-independent subscription path.

The redesign removed the interactive terminal, replaced the projects grid with a readable index, and created a shared header and footer across the site. The published pages require no client-side framework or application server.

The redesign did not require a component library. The important work was deciding what the site should communicate and removing everything that delayed that message.

The Result

The site is less theatrical and more representative of the ideas I want to publish.

The broader lesson applies well beyond personal websites: a technically impressive interface is not automatically an effective one. Good design makes the reader’s next decision easier. Here, that decision is simple—find an idea, decide whether it matters, and inspect the evidence.

The source remains available on GitHub.

← All writing