“If the only tool you have is a hammer, every problem looks like a nail.”
— Probably every senior dev after debugging a junior’s code
In the software world, I constantly see teams reach for their favorite stack — regardless of whether it’s the right fit for the job. A new module? Same stack. A quick tool for internal use? Same stack. A real-time data pipeline? Yep… same stack.
The result? Overengineered solutions, underwhelming performance, and developers silently sobbing into their keyboards.
And I get it. Even I — someone who’s worked with BASIC, Pascal, shell scripting, C, Delphi, PHP, Java, Spring, .NET, Angular, React — have made that mistake. It’s easy to fall in love with the tool you know best. But the longer I’ve worked in software (especially building ERP systems for demanding industries), the more I’ve learned a hard truth:
No tool is good for everything. Every tech decision is a trade-off.
Let’s dig into that.
What Happens When the Tool Dictates the Architecture
You know this scenario:
A team is asked to build a small reporting dashboard.
They reach for their usual weapons: Spring Boot, full REST API, PostgreSQL, React frontend, maybe even Docker and a CI/CD pipeline.
Was the problem complex? Not really.
Did it need all this? Definitely not.
But that’s what they know. So now you’ve got a monstrous mini-project with 12 moving parts, when a single-page app with a SQLite file might have done the job in half a day.
Meme Intermission 🧠
Junior Dev: “We need to build a blog.”
Senior Dev: “Just use WordPress.”
Junior Dev after 6 months of building their own CMS from scratch in Rust with a GraphQL backend, React frontend, and blockchain integration:
Start From Requirements, Not Comfort Zones
If you build enterprise systems like I do, you’ve probably noticed:
- Some parts of your system need rock-solid consistency → relational DBs make sense.
- Some areas need blazing-fast search over massive documents → Elastic or vector DBs might be right.
- For highly dynamic UI interactions? React or similar makes a difference.
- For quick internal tools? Even low-code might work better than a full-stack solution.
But I still see devs trying to solve everything with Spring Boot + PostgreSQL + Angular. Or Node.js + MongoDB + React. Or even .NET for things that don’t even touch Windows.
Why? Familiarity. Comfort. Fear of risk.
The irony? Choosing the wrong tool out of comfort is a bigger risk than learning something better suited.
Why It’s All Trade-offs
There’s no magic bullet. Everything has pros and cons:
- React gives you flexibility — and 10,000 decisions to make before writing a button.
- Spring is powerful — and occasionally eats your weekend debugging autoconfiguration.
- MongoDB is fast and flexible — until you realize you needed transactions.
- PostgreSQL is reliable — until you’re denormalizing like crazy just for performance.
Once you’ve been around enough stacks (and I’ve seen quite a few), you stop asking “What’s the best?” and start asking “What fits this problem?”
Meme Intermission #2 📈
Dev 1: “Why did you rewrite the app in Go?”
Dev 2: “Because Go is fast and can scale to billion users.”
App:
A Better Way to Think
Here’s how I encourage my team (and remind myself) to evaluate tech choices:
✅ 1. What are the real needs?
Is the data relational? Will it scale? Does it need to be real-time? How often will it change?
✅ 2. Who will maintain it?
The best tech in the world is useless if the team hates working with it — or worse, doesn’t understand it.
✅ 3. Is this solving the problem or just showing off?
If the tech stack is starting to look like a spaceship for a paper plane problem, step back.
✅ 4. Can we evolve this later?
Start simple. Prove the value. Then scale. A good MVP is often a smart script or monolith, not a distributed system.
Closing Thoughts
If you take anything from this article, let it be this:
Each job its tool. Each tool its trade-off.
Don’t chase trends. Don’t cling to what you know just because you know it. You don’t need to know everything, but you do need the wisdom to know when to look beyond your comfort zone.
The best developers I’ve worked with aren’t the ones who know 10 languages — they’re the ones who know how to choose.
🧰 Be a software carpenter. Pick the right tool.
🎯 Aim for solutions, not stacks.
💪 Don’t fear the change when you can lead the change.
Top comments (0)