Jekyll. Ruby.
Unusual choices for a modern website, right?

Let me explain.

The Trigger

A week ago, I realized something simple but important:
I had no place to showcase my work, document my learnings, or present myself professionally online.

That had to change.

While planning my portfolio, I thought about two things in parallel:

  • Design philosophy
  • Technology stack

The design direction was clear from the beginning:
Minimal. Clean. Professional. No flashy purple-blue gradients. No unnecessary animation noise. Just content.

The real debate was the tech stack.

The React / Next.js Question

Naturally, I explored modern options first:

  • React
  • Next.js

They are powerful. But that was exactly the problem.

For a static portfolio and blog, they introduce:

  • Additional build complexity
  • Dependency management overhead
  • Larger bundle sizes
  • Continuous framework churn

A portfolio site does not need hydration, client-side routing, or dynamic rendering logic.

Using Next.js for a static site felt like deploying a container orchestration system to serve a business card.

Technically impressive. Practically unnecessary.

Raw HTML & CSS?

Then I considered going old-school.

Just plain:

  • HTML
  • CSS

Simple, right?

Not quite.

As the site grows, manual structure management becomes tedious:

  • Adding new blog posts requires duplicating layouts
  • Updating navigation requires editing multiple files
  • Design consistency becomes fragile
  • Publishing changes involves repetitive effort

It works — but it doesn’t scale gracefully.

For a site that will evolve with projects, skills, and certifications, that approach becomes maintenance-heavy.

Hosting Decision: Vercel, Cloudflare, or GitHub Pages?

I initially leaned toward:

  • Vercel
  • Cloudflare Pages

They’re modern, fast, and reliable.

But for a purely static portfolio, they felt like more infrastructure than necessary.

Then I reconsidered something simpler:

GitHub Pages.

It aligns perfectly with what this project represents:

  • Code-first
  • Developer-centric
  • Version-controlled
  • Transparent

And that’s where I encountered Jekyll.

Why Jekyll Made Sense

Jekyll checked every box.

  • It is purpose-built for static sites.
  • It converts Markdown into fully structured HTML.
  • It integrates seamlessly with GitHub Pages.
  • It requires minimal runtime overhead.
  • It scales cleanly as content grows.

There is also a philosophical alignment I appreciated.

GitHub itself was built on Ruby on Rails.
Jekyll is written in Ruby.

It feels native to the GitHub ecosystem.

But the real deciding factor?

Convenience.

With Jekyll:

  • Adding a new blog post = create a Markdown file.
  • Adding a project = structured data + template.
  • Updating skills or certifications = edit a YAML file.
  • Deployment = push to GitHub.

No framework boilerplate.
No client-side rendering logic.
No overengineering.

Just content and structure.

What Is Jekyll?

Jekyll is a static site generator.

You write content in Markdown.
You define layouts using templates.
Jekyll builds a complete static website.

No databases.
No backend server.
No runtime logic.

Just files.

It is especially popular for blogs and documentation sites, and GitHub Pages supports it natively.

Final Thought

Choosing Jekyll wasn’t about nostalgia or avoiding modern tools.

It was about proportional engineering.

A portfolio and blog should prioritize:

  • Clarity
  • Maintainability
  • Speed
  • Low cognitive overhead

Jekyll delivered exactly that.

Sometimes the best technical decision is not the most hyped one —
it’s the one that fits the problem precisely.