Making Your Own Tools
A running theme throughout my life has always been automating friction away. Whether in my personal life or at work, I’ve always tried to make things easier—for myself and for everyone around me.
Back in my twenties, this mostly manifested as an endless search for the best tool for any given task. That approach served me well for years while I was building my skills and confidence. Eventually, though, my mindset shifted from “What tool should I use?” to “Should I just build this myself?”
Learning Through Building
I’ve never been the type to jump headfirst into a new problem. I preferred taking my time, reading documentation, understanding the landscape, and making informed decisions before writing any code.
Over the past few years, though, that changed. Maybe “impatient” is the wrong word, but I increasingly found tutorials and documentation jumping off point rather than final authority. They’re great for learning syntax or passing an exam, but they rarely provide the understanding that comes from building something real.
Experience certainly played a part. After solving enough similar problems, you develop confidence that you’ll figure things out along the way. Add to that the recent rise of AI-assisted development - and the unexpected influx of free time - and I decided to challenge myself: pick a project, learn some new technologies, and finish it in under a week.
Picking a Tool to Build
The project basically chose itself. My personal website had been sitting unfinished for years.
Part of the reason was time, but a bigger part was that I never wanted to commit to WordPress or some other feature-rich CMS just to publish an occasional post. I wanted something much simpler: write a Markdown file, run a command, and enjoy the newly deployed page.
I didn’t need a visual editor or a complex publishing workflow. I already had my IDE, or even the the Notes app on my phone. Reducing friction had always been the goal, remember?
More Than a Static Site Builder
I wasn’t trying to build the next great static site generator. The real goal was to learn while building it.
Building something from scratch forced me to make architectural and technical decisions that tutorials simply gloss over. Every decision led to another question, and every question opened another rabbit hole. I ended up learning far more than I would have by following a course or recreating a sample project.
Many of those rabbit holes deserve posts of their own. Over the next few articles, I’ll write about the decisions I made, the technologies I experimented with, and the unexpected outcomes I encountered along the way. The static site builder was never really the destination - it was simply an excuse to explore ideas I’d been wanting to play with for a while.
Final Thoughts
One of the biggest lessons DevOps taught me wasn’t Kubernetes, CI/CD, or infrastructure as code. It was that if a task feels repetitive or unnecessarily difficult, you don’t always have to look for a better tool - you can build one.
Almost all of the tools I create will never be used by more than several people, and that’s okay. Making something mass appealing requires very different skills and mindset and it very rarely, if ever, does it make people lifes easier.