Choosing the Wrong Tool Isn't the Tool's Fault
I originally wrote a version of this for Caffeinated Softworks, but the topic struck close enough to home that I wanted to share an edited version of it here too.
A recent piece titled “Why Developers are Quietly Quitting Golang” has been making the rounds. It references a Medium post where a startup founder says that choosing Go (Golang) was “the biggest mistake of [their] life.”
That kind of statement grabs attention right up to the point where it’s clickbait designed to get eyeballs on the page. But, as someone who’s built startups, advised founders, and been burned by plenty of tooling decisions myself, I think the real lesson is buried a bit deeper.
This isn’t a love letter to Go. It’s not a rebuttal about its features, performance, or ecosystem. It’s about the mindset that leads to these situations in the first place.
The Tool Wasn’t the Problem
Startups live and die by their ability to ship and adapt. That means the speed with which you can test ideas, build feedback loops, and adjust course is the first and highest priority for a technical founder. That means choosing tools that support your speed and comfort. If you’re fluent in Python, use Python. If you’ve spent 10 years in PHP, don’t ditch it just because Go seems more scalable. Build first, scale later.
In the article, the founder chose Go because it was “modern” and suited for scalable backends. The problem? They weren’t fluent in it. They were learning the stack while trying to build a business, which is an impossible juggling act for most solo or small-team founders.
It’s tempting to reach for whatever today’s industry darling is — Go, Rust, Bun, Astro, whatever’s trending on HN this week. But hype doesn’t write code. Familiarity does.
New != Better. But Sometimes It Is.
The original article gets something absolutely right: our industry has a shiny-thing problem. We’re constantly chasing the new — often times blindly. That tendency is both a strength and a flaw. It’s how we drive innovation, but also how we end up rewriting stable platforms every two years and wondering why velocity tanks.
But let’s not confuse the industry’s restless nature with a personal obligation to follow it. In a startup setting, “boring tech” often wins because it gets out of your way.
Founders: Use the Language That Lets You Build
If you’re in the early days of your company, your tech stack’s job is simple: help you deliver value fast. Not ten months from now when you hire your first SRE. Right now.
That means leaning into what you know. There’s time to rewrite things later—once you know you’re solving the right problem for the right people. Until then, stack decisions should be boring, obvious, and fast.
Final Thought
I have a lot of empathy for anyone who’s built a startup and lived to tell the tale — whether they succeeded or not. But we’ve got to stop blaming the wrench when we built the wrong fixture. Tech is hard enough as it is.
If you’re building something and feeling stuck—maybe trying to figure out your stack, or wondering if you made the right call early on — I’ve been there. I work with founders through Caffeinated Softworks to help avoid these landmines (or at least step on them with a plan).
Feel free to reach out. Sometimes even five minutes with someone who’s been through it can save weeks of painful second-guessing.