One of my biggest pet peeves when talking with other developers is when the conversation shifts away from who actually needs the product and instead focuses on the stack they like.
Don’t get me wrong—we all have our favorite tools. The frameworks we feel most comfortable with, the libraries we integrate seamlessly into our workflow, the CMS that just clicks for us. And I’m not saying you need to become a jack of all trades, but… well, kind of.
Hear me out. We all love powerful, shiny frameworks. Or that one library that works exactly how we want. Or the CMS that feels refreshingly different from the mainstream options. But here’s the thing—we’re not building for ourselves. We’re building for the end user, the client, or the organization that’s actually paying for the product.
Building with what we personally enjoy, regardless of the project’s requirements or real-world usage, often turns into little more than developer self-indulgence—a way to show off how skilled we are at using a particular tool, or how cool we are for picking an obscure, niche solution. But does that actually serve the people who will be using the site or app? Not always.
A Personal Example: This Site
I love a good Next.js setup. Neatly structured components, well-thought-out routes, smartly nested layout files. Pair it with Tailwind for styling, a sleek set of APIs, and let’s go all-in—AWS AppSync for a modern backend, and Strapi for a headless CMS. It’s clean, modular, and endlessly scalable.
But is all of that really necessary for a personal blog that almost no one will notice?
The overhead alone would be massive. Complex setup, multi-platform deployment, hosting costs, potential hidden fees. And for what? A site that, in the end, would look almost exactly the same? Maybe even worse, given that higher complexity introduces more room for errors.
So what did I go with? A super simple 11ty build. A couple of templates to fit my current needs. Markdown files for posts. Images stored in a Cloudflare bucket. Hosted entirely on Cloudflare, with dead-simple deployment.
Is this my ideal setup? Not really. But it checks every box I needed. It’s easy to maintain, effortless to update, and wasn’t a nightmare to get live.
Why 11ty?
Because I’ve used it before, and—honestly? It wasn’t love at first sight. My first 11ty project was for Google’s DevRel team, and I struggled to catch up because they were using it at an incredibly high level. Everything felt overly complex, and I didn’t understand why they chose it for their sites. But over time, I started appreciating its simplicity, flexibility, and scalability. I used it for a few internal projects, and now it’s just another tool in my toolbox.
Is it my go-to choice? No. It depends on the project. It worked perfectly for my personal site but wouldn’t be the best fit for a client who isn’t comfortable adding content via Markdown and pull requests.
Build for Them, Not Us
The point is, we should focus more on the actual people using what we build. They need to be comfortable. They need to be able to use it daily. They might struggle with radical changes in ways that we, as developers, often don’t consider. We’re a rare breed, after all.
Am I saying we should always stick to old, classic solutions? No. But understanding when and how to move beyond legacy systems is just as important as understanding code itself. There’s a balance between technical innovation and real empathy for the users we’re building for.
Too often, I see developers creating things for themselves first—to prove how skilled they are, to stick to their convictions, to stay in their comfort zones. But something I remind myself of constantly is this: we are always building for the end user. We just happen to have the skills they don’t, to create something they’ll use every day.
Not us—them.