Introduction
Developers love to argue about tech stacks.
Flutter vs React Native.
Native vs cross-platform.
Java vs Ruby vs C#.
React vs Angular.
Riverpod vs Bloc.
Drift vs Hive.
These debates can go arbitrarily deep, down to library-level choices that have little impact on whether a product succeeds or fails.
Everyone has preferences, and that’s fine. Preferences come from experience. Someone who started with strongly typed languages will value compiler guarantees and explicitness. Someone who started with dynamic languages will value flexibility and speed. Both viewpoints are internally consistent.
What they are not is universally correct.
There is no hard data that can rank one stack as objectively “better” across all contexts. Teams, constraints, markets, and goals differ too much. Most arguments rely on anecdotes, and anecdotes do not generalize.
So if preference is not a reliable guide, how should a tech stack be chosen?
By asking a more fundamental question:
What problem are we solving?
You Are Solving a Business Problem
This question is often interpreted at the feature or use-case level. That misses the point.
In almost all non-hobby software, the problem being solved is a business problem.
If there is no business, no users, no revenue, then the software is irrelevant. It may be elegant or technically impressive, but it has no economic value. Software only matters insofar as it supports a business outcome.
That framing matters because it establishes the correct hierarchy.
Technology is not the goal.
Technology is a tool.
And tools are chosen based on the job they need to do.
Why the Stack Rarely Matters at the Beginning
Early on, nobody knows whether the business will work.
You don’t know if users care. You don’t know if they will pay. You don’t know if the problem is real or imagined.
At this stage, obsessing over the “right” stack is misplaced effort. The dominant constraint is uncertainty, not scalability or architectural purity.
“The FIRST rule of enterprenuership is you use what you have” – Alex Hormozi
This is simple rule of entrepreneurship applies surprisingly well to engineering.
Founders and early teams start with what they already know. Not because it is theoretically optimal, but because it minimizes friction. Familiar tools reduce cognitive overhead, increase speed, and allow faster learning.
Early success is rarely determined by technical elegance. It is determined by whether you can ship something people want before you run out of time or money.
When the Stack Starts to Matter
As the business grows, the constraints change.
Revenue appears.
Users depend on the system.
The team grows.
The cost of failure increases.
Now the stack begins to matter more. Not because some technologies are inherently superior, but because the software must support new business realities. Hiring, onboarding, operational cost, maintainability, performance characteristics, and risk management all become relevant.
This is where teams often conclude that an early stack choice was “wrong.” In most cases, it wasn’t wrong. It was right for the phase the business was in. The mistake was assuming it would remain right indefinitely.
A Concrete Example: Twitch
Twitch is often mentioned as a scaling story, but the more interesting part is how long the architecture stayed simple.
At one point, Twitch was serving millions of users with a monolithic Ruby on Rails application and a single PostgreSQL database. That setup was not elegant or future proof, but it worked. It allowed the team to move quickly, ship features, and grow the business without adding unnecessary complexity.
Over time, the constraints changed. Growth amplified failures. Database contention increased. Reliability, support load, and churn started to matter more than raw development speed. The cost of incidents became visible in a way it had not been before.
That was when the architecture began to evolve. The database was scaled and restructured, services were split out, and new infrastructure and languages were introduced. None of this happened because the original stack was flawed. It happened because the business had outgrown it.
The technology changed in response to the business, not the other way around.
If you want to read more about how Twitch migrated from a monolith to microservices, see Breaking the Monolith at Twitch and Breaking the Monolith at Twitch: Part Two.
If you want to know more about how Twitch scaled its database, see How Twitch Uses PostgreSQL.
Agentic Coding Changes the Equation
Agentic coding tools make this even more important.
Tools like Claude Code and Cursor reduce the advantage of deep, framework-specific familiarity. Generating boilerplate, navigating unfamiliar code, applying patterns across modules, and keeping implementation consistent are no longer manual, error-prone tasks.
When an agent can help you stay productive across technologies, the cost of switching or extending a stack drops. What remains expensive is not syntax or APIs, but domain knowledge, product decisions, and the long-term behavior of the system.
In other words, the more the tooling levels the technical playing field, the more tech stack decisions become about business fit.
How to Actually Choose a Stack
Instead of asking whether one technology is better than another in the abstract, ask questions that reflect the reality of the business:
What are we optimizing for right now? Speed, cost, reliability, hiring, or time-to-market?
How quickly do we need to validate this idea?
How expensive will change be later, and what changes are most likely?
What kind of team will maintain this system?
What risks could realistically kill the business, and does the stack reduce or increase them?
Once framed this way, stack decisions become clearer and less emotional. Sometimes multiple choices are equally valid. Sometimes the boring option is correct. Sometimes speed matters more than correctness. Sometimes correctness matters more than speed.
There is no universal answer. The answer depends on the context.
Conclusion
Most tech stack arguments are debates about taste, not outcomes.
Once technology is treated as a business decision rather than a personal identity, those arguments lose their intensity. The question stops being “what do I prefer?” and becomes “what does the business need right now?”
The right stack is not the one that wins debates.
It is the one that helps the business survive and grow at its current stage.
If are starting a project and need help with tech stack decision, connect with me on LinkedIn and I’ll take it from there.