Ask ten people whether your tech stack choice matters and the answers split. Some tell you “don’t overthink it, pick anything reasonable and move on”. Others tell you “pick wrong and you’ll pay for a decade”. They’re both right, for different parts of the same question.
Without a full context (your team, product, budget, customers) words like Technology, Architecture, and Scalability are purely noise, and so are most of the debates around them. The people starting those debates almost never have the context your business actually runs on. Which means that only you can call the shots.
This post helps you make a sound decision. Five signals that matter, noise that fools you, three stories from real businesses. You don’t need an engineering background to use any of it. You just need to know what to ignore and what to ask.
Who this is for
Three kinds of reader.
- You’re commissioning a build and have a proposal in your hand you can’t quite evaluate.
- You’ve got an existing product that’s starting to creak, and the team is talking about a rewrite.
- Your MVP shipped, and now you’re deciding what to build v2 on.
Same framework for all three, because underneath it’s the same question: in three years, will I still be glad I made this choice?
The five signals that actually matter
Walk any proposal through these five. No weighting, no scoring. You’re reading for where the answers get vague or defensive, because that’s where the regret tends to show up a year or two in.
1. Hiring pool
Not “is this popular globally?” The real question is “can I hire my second, third, fifth person for this, where I actually hire?” Go is huge in the global market. Go in the city you’re based in, or your specific remote friendly budget, is a different story. Java still ships half the software in the world and you can spend six weeks and a recruiter’s fee looking for one in a regional Italian city.
The hiring pool is also sometimes not the external market at all. Sometimes it’s the existing staff who’ll be expected to maintain this, and their skills are the constraint that matters more than anything on Hacker News.
Question to ask: “If the lead dev leaves tomorrow, how long and how much to replace them?“
2. Ecosystem maturity
A stack either has a boring, well documented library for every boring thing (auth, payments, file upload, background jobs, scheduled tasks, PDF generation, email), or it doesn’t. Mature ecosystems ship these as commodities. Young or niche ecosystems force the team to rebuild them.
The rebuild time rarely looks bad on paper. It gets estimated as “a few days”, takes weeks, and then pays interest for years because now that code is yours to maintain. You might end up shipping your own authentication library, which nobody ever set out to do but plenty of teams end up doing anyway.
Question to ask: “For auth, payments, and background jobs, are we using well known libraries, or writing our own?“
3. Fit to the problem shape
Most business software is CRUD: forms, lists, reports, permissions, a database behind them. That kind of work fits comfortably on any boring general purpose stack, and in those cases the hard part is almost never the technology, it’s figuring out what the product needs to do.
But when the problem genuinely is not CRUD, the picture changes. ML heavy work belongs on Python because that’s where the ecosystem lives. Frontend heavy products benefit from TypeScript end to end, because running one language across the stack cuts context switching and promotes code reuse. This is where language choice becomes a real decision instead of a religious one.
Team fluency is part of the fit too. A team already shipping in React will outrun a team that’s switching from Angular. The gap is larger on stacks with sharper edges. Picking something the team doesn’t know, with nobody to show them the way, stretches every estimate and buries landmines you’ll step on a year in.
The question to ask is: “What about our product makes this technology a better fit than the boring default?” A reasonable answer can be “it fits what we’re building better, besides, we’d be reinventing things the standard library already gives us” or even “nothing about the product, but the team wants it, and is willing to own the risk.” That’s still legitimate. The smell is when the honest answer is just “we prefer it”, with no valid reason to back it up.
4. Operational surface area
How much infrastructure does this stack demand you run? A monolith on a managed host (Railway, Render, Fly, etc.) is low surface. Eight microservices on Kubernetes with their own queues, service mesh, and observability layer is high surface. The surface is a permanent cost, paid in either headcount or downtime.
Deploy, maintenance, and on call shouldn’t be afterthoughts. If the answer to “who handles production at 2am?” involves a person your business can’t afford to keep on payroll, the architecture is wrong for your business regardless of how elegant it looks.
Ask: “What does our deploy and our on-call look like the day after we launch?“
5. Lock in and portability
Can you leave? Firebase only, welded to a single cloud provider, or tied to proprietary technology: moving costs a full rewrite. Postgres + a mainstream language + a boring web framework: moving costs a backup and some configuration changes over three nights.
Lock in is not automatically wrong. Firebase on day one might genuinely save the six weeks you don’t have. But it should be a decision, not an accident. Saying we’re buying speed now and we know this will cost us if we outgrow it is legitimate. Ending up there by default, with no exit in mind, is how teams find themselves stuck years later.
Question to ask: “If our cloud bill doubles or this vendor pivots, what does a migration look like?”
The noise that fools founders
With the five signals in hand, it’s easier to see why the following don’t belong in the same list, even though they sound like they should.
“It is faster.” Raw performance benchmarks that ignore everything your product actually does. It’s the equivalent of putting premium fuel in a city car, expecting it to go faster. The real question is whether the technology fits the problem shape (the third signal).
“It scales.” Scale is a problem you earn. Most products never reach the scale where the answer matters, and designing for imaginary scale early is how you end up with the microservice tax before you have revenue.
“X is better than Y” This debate is meaningless without context: team fluency, problem fit, seniority. Same technology, different economics depending on the team. “Which is better” is the wrong question. “Which is better for us, given who we are and what we’re building” is the right one.
“Our CTO friend uses it.” Secondhand confidence. Their context is not yours. The stack that works at their 50-engineer team fails at your two-person contract build, and vice versa.
“It is modern.” Being newer isn’t, on its own, a reason to pick something. If something really is an improvement, work out which of the five signals above it actually helps, what it costs on the others.
Three stories
The microservice rewrite that outgrew its own product
A SaaS that started life as an on premise monolith went multi tenant, and the team used the rewrite as an excuse to go full distributed systems. Microservices, Kubernetes, and everything that goes with them. Within a year, the boilerplate per service was larger than the business logic it was holding.
Such a small team couldn’t manage that much complexity, so they hired. The hires forced process. The process calcified into silos, with each team owning a handful of microservices and evolving them in different directions. Different patterns, different libraries, and eventually different languages altogether. By year three they were paying a handful of engineering salaries for a product whose revenue couldn’t support half of them.
Through the framework:
- Fit to problem (signal 3) failed. Microservices make sense at genuine scale and genuine complexity, with enough people to own each piece. This team was small. The product wasn’t that complex. The scale didn’t need splitting.
- Operational surface (signal 4) failed, because the surface they signed up to run was what forced the headcount that forced the silos.
Besides that, the “it scales”, “it’s faster”, “it’s modern” and the “x is better than Y” noise was all present from day one, if anyone had been willing to name them.
Every new hire was spending most of their time on problems the rewrite itself had created.
Beautiful software, nobody to hire
A company running on Elixir, with newer pieces in Rust. The code was genuinely good. People liked working on it. The hiring math was the problem. Every time they needed someone new, they paid a premium just to find candidates willing to learn the stack, before those candidates were productive.
Elixir and Rust are both excellent, and this same stack at a hot SF startup with an engineering magnet brand would run just fine. But it failed here, because the business running it had a normal European hiring pipeline, and that pipeline couldn’t cheaply deliver people who already knew those languages.
The code was a pleasure to work on. Hiring for it wasn’t.
The stack that matched the people, not the freelancer
A mid sized company heavily invested in Microsoft products contacted me for advice on an internal application. No software engineers on staff. They did have an IT team that could read and write code, maintain servers, and had been keeping the existing business systems running for years.
A modern web stack (Node + Postgres + Railway), would have technically worked. It would also have left them with something nobody on their team could keep running after I left. So the recommendation was .NET + SQL Server, on their existing Windows infrastructure. Not because .NET is a personal favourite. Because the maintenance team was already in place, already Windows-native, already knew the shape of the tooling, and had Active Directory, backups, and a deployment story provisioned before I walked in the door.
Through the framework:
- hiring pool (signal 1) applied correctly: the pool was the existing IT staff, not the external market.
- Operational surface (signal 4) was low, because the environment was already there.
- Lock in (signal 5) was negligible, because extending an ecosystem the company was already committed to isn’t new lock in.
The right stack was the one the people who would live with it already knew.
The takeaway
Technology choices matter less than founders fear in some ways, and more than they think in others. The debates on offer (language favoritism, abstract scale arguments, monolith vs microservices as religion) don’t meaningfully change the outcome. What does change it rarely gets asked in time: who can maintain this, what does it demand to run, does it fit the shape of the product, can we leave if we need to.
The framework isn’t a scorecard, more of a prompt for the conversations that usually don’t happen early enough. Walk a proposal through the five signals and pay attention where the answers come back vague or rehearsed, as those are the ones worth pushing back on. Asking these questions takes little time, but the answers are worth years of runway.
If you’re dealing with this right now and don’t know what to push back on, I’d be happy to help you think it through.