Choosing a Tech Stack: A Framework for the Decision, Not a Stack Recommendation

Beyond Cost and Technical Debt

Our guide on MVP development already covers real cost and timeline data for a first build. Our guide on production-grade software and technical debt already covers what technical debt actually is and what it costs once it accumulates. Neither answers the question this guide is written for: how do you actually decide which languages, frameworks, and tools to build on in the first place, before any of that cost or debt exists yet?

Why “Best Stack” Is the Wrong Question

The question “what's the best tech stack” assumes a fixed ranking exists independent of who's asking, which isn't how this decision actually works in practice. The right framework for a two-person team with deep existing expertise in one language is different from the right framework for a well-funded team hiring specialists from scratch, which is different again from a team building a product with genuinely unusual technical requirements. Treating this as a search for one correct answer — the way founders sometimes treat it, hunting for the “right” framework the way they'd hunt for the right pricing model — skips past the actual decision, which is really a weighing of trade-offs specific to your own situation.

This reframing matters because it changes what a founder should actually be reading and researching. Instead of searching for “best programming language 2026” and trying to reverse-engineer a ranking into a decision, the more useful exercise is working through a small number of concrete criteria against your own specific situation — which is what the rest of this guide covers in detail, with real data behind each criterion rather than opinion alone.

The Real Decision Criteria

Team familiarity deserves to be weighed more heavily than it usually is, because the cost of learning a new technology while simultaneously trying to build and ship a real product is a real, compounding cost that's easy to underestimate from the outside. A team that already knows a language well can move faster and make fewer subtle mistakes in it than the same team learning a “better” language for the first time under deadline pressure — and a startup's scarcest resource is usually calendar time, not code elegance. Hiring pool size is the second criterion, and it's worth thinking about specifically, not abstractly: a technology that's popular globally but has few practitioners in your specific hiring market or price range doesn't actually give you the hiring flexibility the global popularity number implies.

Ecosystem maturity is the third criterion, and it's specifically about whether the libraries and tools your product actually needs already exist and are well-maintained, not about the language's general reputation. A newer or smaller ecosystem can be a perfectly reasonable choice if it happens to have excellent, mature libraries for exactly what you're building — the criterion is specific to your product's actual needs, not a general maturity score. Long-term maintenance burden is the fourth and most consequential: whatever you choose, you're very likely stuck with a version of it for years, since a full rewrite is expensive and risky (a point covered in detail later in this guide) — so the question worth asking isn't just “can we build this quickly” but “can we live with this for the next several years, including hiring for it and keeping it updated.”

A worked example: applying the four criteria to a real decision

It's worth walking through a concrete scenario rather than leaving the four criteria abstract. Consider a two-person founding team where both founders have several years of professional experience in one language, building a B2B SaaS product with fairly conventional requirements — a web application, a database, some background jobs, no unusual performance or hardware constraints. Team familiarity here points strongly toward staying with the language the founders already know well, since the alternative — learning a new language while also trying to find product-market fit under real time pressure — adds a second, simultaneous learning curve on top of the already-difficult problem of building the right product. Hiring pool size is the next check: does that language have a reasonable number of practitioners in whatever market this team plans to hire from, at a price point the company can afford once it needs to grow the team? For most mainstream languages represented in the Stack Overflow data above, the answer is yes; for a genuinely niche or declining choice, this is exactly where the New Jersey COBOL lesson, covered later in this guide, becomes directly relevant.

Ecosystem maturity is the third check in this scenario: does the language have mature, well-maintained libraries for the specific things this B2B SaaS product needs — a web framework, an ORM or database layer, authentication tooling (exactly the kind of commodity capability our API and integration strategy guide covers), background job processing? For a conventional product like this one, most mainstream languages clear this bar comfortably, which means the decision often comes down overwhelmingly to the first criterion, team familiarity, rather than any meaningful difference in ecosystem capability between the reasonable options. Maintenance burden, the fourth check, asks whether this team can realistically keep this stack updated, secure, and staffed for the multi-year life of the product — a question best answered by confirming the language and its major frameworks have an active, ongoing release cadence and a real community still producing updated documentation and libraries, not one that's visibly stagnating.

Real Data: What Languages Are Actually Popular

Stack Overflow's 2025 Developer Survey is the most authoritative, widely cited annual source on this exact question, and its findings on most-used languages among all respondents are worth citing precisely: JavaScript (66%), HTML/CSS (61.9%), SQL (58.6%), Python (57.9%), Bash/Shell (48.7%), and TypeScript (43.6%), based on 31,771 responses to the technology question specifically (Stack Overflow, 2025 Developer Survey, Technology). GitHub's own Octoverse 2025 report, published October 28, 2025 and covering the period from September 2024 to August 2025, found a genuinely significant shift: TypeScript overtook both Python and JavaScript to become GitHub's most-used language by contributor count, with roughly 66.63% year-over-year growth — described by GitHub as the first major change at the top of that ranking in over a decade (GitHub, Octoverse 2025). The same report found Python added roughly 850,000 contributors (up 48.78% year over year) and JavaScript added roughly 427,000 (up 24.79%), and that roughly 80% of new repositories used just six languages — a useful, concrete measure of how concentrated real-world adoption actually is around a small set of established options.

Popular vs. Admired: A Crucial Distinction

It's worth naming a distinction the Stack Overflow survey itself makes explicit, since founders researching a stack choice frequently conflate the two: the languages developers most widely use are not the same as the languages developers most admire or want to use more of. The same 2025 survey found Rust the most “admired” language at 72%, followed by Gleam at 70%, Elixir at 66%, and Zig at 64% — none of which rank anywhere near the top of the most-used list above. This gap is directly informative for the decision framework covered earlier: a technology developers love working with isn't automatically the technology with the largest available hiring pool, the most mature ecosystem for a typical product's needs, or the lowest long-term maintenance risk. Choosing a stack based on what developers say they'd most like to use, rather than the criteria that actually determine whether your company can build and staff a product successfully, is a specific, real version of the resume-driven-development mistake covered in detail later in this guide.

The “Boring Technology” Philosophy

McKinley's essay is a real, precisely dated, individually authored piece, confirmed directly at his own site (Dan McKinley, “Choose Boring Technology,” March 30, 2015). His central argument is the “innovation tokens” framing: an organization has a limited budget of novelty it can successfully absorb at once, and every genuinely new, unproven technology choice spends one of those tokens — meaning fewer tokens remain for the actual product risk that matters, the thing your company is supposed to be differentiated on in the first place. His own stated reasoning is direct: “the long-term costs of keeping a system working reliably vastly exceed any inconveniences you encounter while building it,” which is exactly why mature, boring technology — Postgres, MySQL, cron — with well-understood failure modes and mature documentation should be the default choice, reserving genuine innovation for whatever your product actually needs to be novel about.

“The long-term costs of keeping a system working reliably vastly exceed any inconveniences you encounter while building it.”

— Dan McKinley, “Choose Boring Technology,” March 2015

McKinley also proposes a concrete process worth adopting directly: try to solve the problem with your existing stack first, document the specific, concrete limitations you actually hit before considering something new, and require real organization-wide buy-in before adopting anything genuinely novel. This process is useful precisely because it forces a team to articulate a specific, checkable reason for reaching for something new, rather than reaching for it because it's interesting or currently fashionable — converting a vague instinct into a documented, defensible decision.

Applying innovation tokens in practice, not just as a slogan

McKinley's framework is easy to nod along with in the abstract and harder to actually apply in a real decision, so it's worth being concrete about what “spending a token” looks like in practice. A token is spent whenever a team adopts a technology whose failure modes, performance characteristics, and long-term maintenance requirements aren't yet well understood by the team adopting it — not necessarily a technology that's objectively new to the industry, but one that's new to the specific people who will be operating it. A well-funded team with a senior engineer who has genuinely deep, multi-year production experience with a newer database isn't spending a token the same way a team adopting that same database with zero prior collective experience is — the framework is about your organization's actual, specific unfamiliarity, not the technology's calendar age. This distinction matters because it corrects a common misreading of McKinley's essay: “boring” isn't a property of the technology in isolation, it's a property of the relationship between the technology and the specific team operating it.

The ThoughtWorks Radar and the “Hold” Ring

A second, real, ongoing source worth knowing for the maturity-assessment part of this decision is the ThoughtWorks Technology Radar, a biannual publication produced by a named ThoughtWorks advisory board including CTO Rebecca Parsons (ThoughtWorks Technology Radar). The Radar organizes technologies into four rings, and its “Hold” ring is directly useful for assessing ecosystem maturity in practice: originally meaning “too new to reasonably assess,” the category has evolved, per ThoughtWorks's own materials, into a more direct “don't start anything new with this” signal — a genuinely useful, ongoing, expert-curated check against a specific technology's current maturity, updated twice a year rather than reflecting a single, dated opinion. For a founder without deep in-house expertise across every technology option, checking a specific candidate technology against the Radar's current placement is a fast, credible sanity check before committing. The Radar also has three other rings worth knowing in outline — “Adopt,” “Trial,” and “Assess” — which together form a rough maturity gradient from proven-and-safe to genuinely experimental, so a technology's specific ring placement is more informative than a binary yes-or-no read on whether it is safe to build on.

Language Choice vs. Framework Choice: Two Different Decisions

It's worth separating a distinction this guide has treated loosely so far, since the two decisions carry meaningfully different stakes. Choosing a programming language is the deeper, harder-to-reverse decision — it determines your entire hiring pool, your team's learning investment, and the broad category of tooling available to you, and changing it later means something close to the full Instagram-style migration effort covered below, just typically worse since most real migrations involve a genuine language change, not merely a version upgrade. Choosing a specific framework within that language — which web framework, which ORM, which testing library — is a real decision too, but one with meaningfully lower switching costs in most cases, since the underlying language, the hiring pool, and the team's core skills stay constant even if a specific framework is later swapped out.

This distinction is worth keeping explicit because it changes how much scrutiny each decision deserves. The four criteria covered throughout this guide apply to both decisions, but the cost of getting the language choice wrong is categorically higher than the cost of getting a specific framework choice wrong, which argues for spending disproportionately more upfront deliberation on the language decision specifically, while treating framework choice within an already-chosen language as a lower-stakes, more reversible decision that doesn't need the same exhaustive process. A team that spends weeks debating between two web frameworks in the same language they've already committed to, while having spent comparatively little time on the language decision itself, has likely allocated its deliberation effort backwards relative to where the real risk actually sits.

Resume-Driven Development

This peer-reviewed source, presented at the 43rd International Conference on Software Engineering's Software Engineering in Society track, gives resume-driven development real academic grounding rather than leaving it as an informal industry term (Fritzsch, Wyrich, Bogner, and Wagner, “Résumé-Driven Development,” ICSE-SEIS 2021). The underlying dynamic is worth stating plainly for a founder evaluating a stack recommendation from a specific engineer or team: an individual engineer's career incentives (wanting hands-on experience with a currently in-demand technology to strengthen their own future job prospects) don't always align with the company's incentives (choosing whatever actually serves the product and the business best over the next several years). This isn't necessarily a claim of bad faith — most engineers advocating for a newer technology genuinely believe it's the right technical choice — but it's a real, structural incentive worth being aware of specifically when a recommendation happens to align neatly with what's currently generating the most excitement in the broader industry, independent of your product's actual requirements.

The practical countermeasure isn't distrust of engineering recommendations generally — it's asking a specific, direct follow-up question whenever a novel technology is proposed: what specific, concrete limitation of the current, more established option does this new choice solve, and is that limitation something your product has actually hit, or something it might hit hypothetically at a scale you haven't reached. This is precisely the same discipline McKinley's boring-technology process recommends, applied as a direct question in the room rather than an abstract principle.

The Real Cost of an Obscure Stack

The New Jersey case is real, well-corroborated across multiple independent outlets, and worth knowing precisely: in April 2020, Governor Phil Murphy publicly requested volunteer COBOL programmers after the state's decades-old unemployment system, built on the language, buckled under a surge to 362,000 unemployment applications during the early COVID-19 pandemic (CNBC, April 6, 2020; corroborated separately by CNN Business, April 8, 2020, and multiple other outlets). It's worth being precise about the limits of the direct parallel to a startup's stack decision: this is a case of decades of legacy accumulation in a public-sector system, not a company choosing an obscure technology at inception the way this guide is primarily concerned with. This research could not find a comparably well-documented, named private-sector startup case of a hiring crisis tied specifically to an obscure or declining stack choice made at founding — which is worth stating honestly rather than inventing a startup-specific case that doesn't exist in verifiable reporting.

What the New Jersey case does illustrate clearly, and what does transfer directly to a startup's decision, is the underlying mechanism: a technology's available talent pool doesn't stay fixed over time, and a choice that seemed reasonable when the talent pool was larger can become a genuine operational constraint years later when you need to hire quickly and the remaining practitioners are scarce, expensive, or both. This is precisely why the hiring-pool criterion covered earlier in this guide deserves ongoing attention, not just a one-time check at the moment of initial choice — a technology's hiring pool is a moving target, and a founder making a long-term stack commitment is implicitly betting on where that pool will be years into the future, not just where it stands today.

What a Real Migration Actually Costs

This is a genuinely well-documented, real, named migration case, presented directly by the Instagram engineers who ran it at PyCon 2017 (Hui Ding and Lisa Guo, “Python 3 at Instagram,” PyCon 2017). The reported timeline breaks down into roughly three months of code modification, two months of testing, and four months of production rollout, completing the full migration to Python 3.6 by early February 2017 — a full ten months of sustained engineering effort for a single language-version migration at Instagram's scale. Reported technical outcomes, corroborated across multiple independent secondary sources covering the same talk, include roughly a 12% reduction in CPU instructions per request and up to a 30% memory reduction on Celery workers — genuinely meaningful performance gains, but earned only after a ten-month, deliberately incremental effort using multi-version testing and continuous deployment specifically to avoid downtime during the transition.

It's worth being precise about what this case does and doesn't prove. Instagram's migration was between two versions of the same language, not a switch between fundamentally different languages or frameworks — genuinely one of the least disruptive kinds of migration available, and it still took ten months of focused engineering effort at a company with substantial engineering resources. A migration between genuinely different technologies (a different language, a different framework paradigm) is reasonably expected to take considerably longer and carry meaningfully more risk than this case demonstrates, which is precisely why the initial stack decision this guide covers deserves real upfront care — the cost of getting it wrong isn't primarily about looking back and wishing you'd chosen differently, it's about the real, multi-month-to-multi-year cost of actually changing course once a product is live and depended on.

A second, real, widely known case worth naming in outline, though with less precise cost data available: Twitter's migration away from its original Ruby on Rails backend, beginning around 2008 when its Ruby-based message queue hit real scaling limits, moving its backend message queue and Tweet storage to Scala on the JVM, with its search infrastructure following a similar path starting around 2010. By the 2012 U.S. election, Twitter's JVM-based infrastructure handled election-night traffic without the repeated outages that had plagued the platform in its earlier, more Rails-dependent years — a widely reported before-and-after covered contemporaneously by The Register in November 2012. It's worth being direct that no specific, verifiable dollar cost or headcount-months figure for this migration was ever publicly reported by Twitter itself, so this guide states only the well-corroborated shape of the story (began around 2008, largely complete by 2012) rather than inventing a specific cost figure that was never actually disclosed.

Recognizing a genuine signal to migrate versus a fashionable one

Given how expensive a real migration is, even in the best-documented, most incremental case available (Instagram's own ten-month effort), it's worth being explicit about what actually constitutes a genuine signal to migrate versus a fashionable impulse to rewrite. A genuine signal looks like Twitter's own documented experience: a specific, measurable, recurring operational failure (their original Ruby-based message queue hitting real, repeated scaling limits) that the current stack cannot be reasonably patched or scaled around within its existing architecture. A fashionable impulse, by contrast, looks like wanting to move to a newer technology because it's generating industry excitement, because a specific engineer wants the experience on their resume (the exact dynamic the resume-driven-development research above studies directly), or because the current stack simply feels old, without a specific, documented operational failure driving the decision. The test worth applying directly: can you name the exact metric or operational failure the current stack is causing, the way Twitter could point to specific, repeated outages tied to its original queue architecture? If the answer is a specific yes, the calculus shifts meaningfully toward migration being justified. If the answer is a vague sense of staleness, it likely isn't.

The Lesson Behind “Never Rewrite”

A related, well-known essay worth knowing in this context, even though it's specifically about full application rewrites rather than initial stack selection, is Joel Spolsky's “Things You Should Never Do, Part I,” published April 6, 2000, which uses Netscape's roughly three-year full rewrite (begun in 1997) as its central example (Joel Spolsky, “Things You Should Never Do, Part I,” April 2000). Spolsky's argument, in outline: Netscape spent roughly three years rewriting its browser from scratch, during which it shipped essentially nothing new to a market where Internet Explorer continued to ship and improve, and by the time the rewrite was finished, Netscape had lost the market position the rewrite was partly meant to protect. It's worth being precise that this essay is about the risk of a full rewrite of an already-successful product, not directly about choosing a stack for a new one — but the underlying lesson connects directly to this guide's broader argument: the real cost of changing your technology foundation later is severe enough that the upfront decision, covered throughout this guide, deserves real weight precisely because undoing it is this expensive.

A Practical Decision Framework

Bringing the research above together into an actual decision process:

1. 1

   Default to what your team already knows well, unless there's a specific, documented reason not to

   Per McKinley's process: try solving the problem with your existing stack first, and require a concrete, articulated limitation before reaching for something new.

2. 2

   Distinguish "most used" from "most admired" before choosing based on developer sentiment

   Stack Overflow's own 2025 data shows these are genuinely different lists — a technology developers love isn't automatically the one with the largest hiring pool or most mature ecosystem for your needs.

3. 3

   Ask what specific limitation a proposed new technology actually solves

   The direct countermeasure to resume-driven development: require the person proposing a novel technology to name a concrete limitation of the current option your product has actually hit, not a hypothetical one.

4. 4

   Weigh the real, multi-month cost of changing course later before committing

   Instagram's own well-documented Python 2-to-3 migration took ten months for a same-language version upgrade — a genuinely different-technology migration should be expected to cost considerably more, which is exactly why the initial decision deserves real care.

Revisiting the Decision as the Company Grows

It's worth closing with an acknowledgment that this decision isn't made once, permanently, and then forgotten — it's a decision that gets implicitly re-affirmed every time a new engineer is hired, a new service is added, or a significant new feature is scoped, and it's worth occasionally re-examining deliberately rather than only implicitly. The four criteria this guide covers don't stay fixed over a company's life: a hiring pool that was thin when a startup chose its stack can widen considerably as a language grows in popularity (or narrow considerably as one declines, precisely the risk the New Jersey case illustrates), and a maintenance burden that felt manageable with two engineers can become a real constraint with twenty. None of this argues for reflexively questioning the original decision constantly — that would recreate exactly the kind of unstable, fashion-driven churn this guide argues against — but it does argue for treating the original stack decision as a live, periodically re-examined commitment rather than a one-time choice made at founding and never revisited until a crisis forces the question.

The specific, practical version of this habit worth adopting: whenever a genuinely new class of engineering problem shows up — a new kind of workload, a new scale of traffic, a new team member who surfaces a real limitation nobody had previously hit — run that specific situation back through the same four criteria this guide opened with, rather than either reflexively defending the original choice or reflexively assuming it's now outdated. Most of the time, the original decision will hold up fine against a new situation, precisely because the criteria that made it reasonable at founding — team familiarity, a real hiring pool, mature ecosystem support, manageable maintenance burden — tend to compound favorably over time rather than degrading, for a technology that was genuinely well-chosen in the first place. When the original decision does eventually stop holding up, the same research this guide has walked through — the real cost of the McKinley process, the real, checkable signal Twitter had, the real ten-month cost Instagram paid even for an incremental, same-language migration — is exactly the framework worth applying to that later decision too, not a separate, unrelated question.

That last point is worth restating on its own: this guide has intentionally never named a specific language or framework as the recommended choice, and that omission is the point rather than an oversight. Every piece of real data and every named case study covered here exists to sharpen the questions a founder should ask about their own specific team and product, not to substitute for that judgment with someone else's ranking.

Frequently Asked Questions

None of the research in this guide points toward a specific stack recommendation, because that was never the right question to answer. What it points toward is a repeatable process: weigh your team's actual expertise honestly, check your real local hiring pool rather than global popularity data alone, verify ecosystem maturity against your product's specific needs, and treat any genuinely novel technology choice as spending a scarce, limited budget best reserved for whatever actually makes your product different. The founders who get this decision right aren't the ones who found the objectively best stack — they're the ones who asked the right questions about their own specific situation, rather than outsourcing the decision to whatever ranking or trend happened to be circulating at the time they had to choose.