There is a conversation that happens in almost every engineering team at some point.
It usually starts with something like: "Should we be using Go instead of Node.js?" or "Java feels outdated, maybe we should migrate to Kotlin." Hours of debate follow. Benchmarks get shared. Blog posts get cited. Someone pulls up a ThoughtWorks Technology Radar.
And at the end of it, the team feels like they did something productive.
They didn't.
---
The Trap: Stack Debates Feel Productive But Often Aren't
Choosing a technology stack feels like a high-leverage decision. And in some cases, it is. But most of the time, teams spend far more energy debating the stack than it deserves — because it's easier to debate tools than to confront the harder question: are we shipping well?
Stack debates are intellectually stimulating. They involve interesting tradeoffs, strong opinions, and no immediate consequences. You can spend a week comparing Go's concurrency model to Node.js's event loop and never write a single line of production code.
The uncomfortable truth is this: the stack rarely determines whether a project succeeds or fails. The team does.
---
What Actually Determines Execution Speed
Think about the best engineering teams you've encountered. What made them fast? It almost never came down to their language or framework choice.
What actually separates fast teams from slow ones:
Deep familiarity with the stack. When a team knows their tools well, there's no learning tax. They don't stop to look up how middleware works, or spend three days figuring out the ORM's edge cases. That accumulated knowledge compounds over time — a team six months into a stack ships faster than a team on day one with the "optimal" stack.
Shared conventions. Fast teams have settled opinions about how things should be done. Where files go, how errors are handled, how services communicate. These conventions eliminate a constant source of micro-decisions and code review friction.
Good engineering practices. Tests, CI/CD, observability. These matter regardless of stack. A team with solid practices on Node.js will outrun a team with poor practices on Go every single time. The stack doesn't write the tests — the team does.
These things compound. A team that invests in familiarity, conventions, and practices gets faster every month. A team that switches stacks every two years resets that compounding clock each time.
---
When Stack Choice Does Matter
None of this means stack choice is irrelevant. There are real cases where it matters significantly.
Hard technical constraints. If you're building ML pipelines, Python is not just a preference — it's where the ecosystem lives. If you're writing infrastructure tooling or a high-concurrency network proxy, Go's runtime characteristics are genuinely superior. Some problems have a natural fit, and ignoring it is stubborn.
Talent availability. The best architecture in the world is a liability if you can't hire people to maintain it. A Haskell codebase might be elegant, but your hiring pool just got an order of magnitude smaller.
Long-term maintainability. Some stacks age better than others in your specific domain. Enterprise business applications have decades of tooling, patterns, and framework support in .NET and Java. Greenfield consumer apps have rich ecosystems in Node.js and Python. This matters when you're thinking five years out.
Ecosystem maturity. If your domain has a well-established ecosystem in one stack — payment integrations, healthcare HL7 parsing, game server SDKs — swimming against that current has real costs.
The key distinction is this: stack choice should be driven by real constraints, not theoretical ones.
---
The Real Cost of Switching Stacks
When teams do decide to switch stacks, they almost always underestimate what they're giving up.
The obvious costs are visible: rewriting code, learning new tooling, updating deployment pipelines. But the hidden costs are what hurt.
Lost institutional knowledge. Every team accumulates years of learned behavior — why that service has a weird timeout, what the edge case in the payment flow is, why the retry logic works the way it does. That knowledge lives partly in the code and partly in the team's heads. When you rewrite, you often lose the second half.
Operational patterns reset. Your team knows how to debug a memory leak in your current stack. They know which metrics matter, which errors are noisy, which alerts are real. Starting over means rebuilding that operational intuition from scratch — usually under production pressure.
Morale hit. Rewrites are demoralizing when they drag on. What started as an exciting greenfield project becomes a slog when the deadline slips and the old system is still running in parallel, demanding maintenance.
Migrations are sometimes worth it. But they should clear a high bar: a genuine technical wall you've hit, not a vague sense that the grass is greener.
---
How to Actually Make the Decision
If you're genuinely at the point where a stack decision needs to be made — new project, or real evidence the current stack is the bottleneck — here's a more grounded approach:
Start with your team's strengths. What does your team know well? What can they move fast in today? A skilled Python team will ship a Python service faster than they'll ship a Go service, even if Go would theoretically be more performant for the use case. Unless performance is a hard requirement, familiarity wins.
Identify real constraints, not theoretical ones. Is there an actual problem your current stack can't solve? A performance wall you've measured? A library you genuinely need that doesn't exist in your stack? If the constraint is theoretical, it's not a constraint yet.
Switch deliberately, with a clear payoff. If you must migrate, define what success looks like before you start. What specific metric improves? What problem goes away? If you can't answer that clearly, you're migrating for the wrong reasons.
Prefer evolution over revolution. Strangler fig pattern, incremental rewrites, introducing a new service in the new stack alongside the old one — these are usually safer than big-bang rewrites.
---
People Over Tools
There's a phrase that gets thrown around in engineering: "use the right tool for the job." It's true, but incomplete. The full version is closer to: use the right tool for the job, given the team you have, the constraints you're working within, and the time horizon you're optimizing for.
A great team with Node.js will outship a mediocre team with Go every time. Not because Node.js is better — it isn't, in many dimensions — but because execution is a function of people, not tools. The team's familiarity, discipline, and cohesion matter more than which runtime they're using.
The best stack is the one your team can execute with — the one they know deeply, have conventions around, and can debug at 2am without a Slack thread asking what library handles X.
It's usually boring. It's usually the one you already have.
And that's exactly the point.