As I got better with Bootstrap, something predictable happened: I wanted to optimize everything.
Designing pages was fun. Publishing blogs felt good. It even felt a little cinematic—like those scenes in The Social Network where things are constantly being built and shipped.
(No, I wasn’t obsessed. Maybe a little.)
But I started noticing the friction. Every new post meant opening a full HTML file. Copying structure. Re-checking headers and footers. Fixing spacing. Only then could I start writing. I didn’t want that anymore. I wanted to write first and let the site worry about the rest. I didn’t have the words for it then—I didn’t know about components or templating—but I felt it was inefficient.
I tried self-hosted WordPress for a bit. It worked. But it came with baggage: databases, backends, admin panels, things breaking for reasons I didn’t understand. All I wanted to do was write and publish. Nothing more.
So I kept looking. Somewhere in that search, I ran into static site generators. Hugo came up. A few others too. But Jekyll stuck—mostly because of a DevTips tutorial and its seamless integration with GitHub Pages.
Discovering Jekyll
Jekyll felt intimidating at first. Not because of what it promised, but because of Ruby. I didn’t know Ruby. I still don’t. But I wanted what Jekyll offered badly enough to push through that discomfort.
The idea itself was simple. Almost elegant. No database. No PHP. No queries. Just files and layouts. It was too good to be left alone.
The Messy Setup
Setting up Jekyll was messy. Ruby versions didn’t match. Gems failed to install. The typos I made in templating or even the front matter itself made the Terminal yell at me more than once with cryptic errors.
I didn’t fully understand what I was installing. I was following tutorials and documentation, copying commands, hoping nothing broke. Sometimes it did. Sometimes the site just wouldn’t build and I had no idea why. But little by little, things started to make sense.
Learning the Structure
Front matter was the hardest part at first. A few lines at the top of a file controlling an entire page felt strange. Layouts felt abstract. Includes felt like cheating.
Until they didn’t.
I started moving my old Blogspot posts into Jekyll. I broke the site multiple times. Entire builds failed. Pages vanished. And despite hosting everything on GitHub, I had no real understanding of version control yet. I was committing blindly and hoping for the best.
Looking back, it’s funny. The tools were already there—I just didn’t know how powerful they were. And it still serves as a reminder: we often mistake unfamiliarity for incompatibility. When something doesn’t bend to our will immediately, we assume we need a better tool, when what we really need is more understanding of the one in front of us.
When It Finally Clicked
Eventually, it clicked. I had a site that felt like mine. Fast, predictable, and easy to write for. That idea stuck with me. It still has.
Even now, this site runs on Astro, a modern version of the same instinct. Static at its core. Structured. Intentional.
Jekyll didn’t just teach me how to build a website. It taught me that good systems reduce friction.
When structure is done right, you stop noticing it. And you finally get to focus on what you wanted to do in the first place, a concept I carry into design every day.
In the next part, I’ll write about what happened when publishing became effortless, and how that changed my relationship with showing work.