Stack Churn: A Decision Framework for Tech That Lasts

Q: What is stack churn and why is it so expensive?

Stack churn is the pattern where a team repeatedly replaces working technology with newer technology, each replacement justified in trend language rather than by a problem the business actually has — and it is expensive because the cost is mostly invisible in any single decision while being enormous in aggregate. The mechanics: a stack is adopted because it is ascendant, the team spends months or a year learning its idioms and operational quirks, the ecosystem shifts, the original choice is now described as "legacy," and a migration is proposed. Each individual step has a defensible-sounding rationale. What the aggregate produces is a roadmap where a substantial fraction of engineering capacity goes to re-implementing functionality that already worked, in a new idiom, with no customer-visible outcome to point at. Three cost categories compound. Direct migration cost is the visible one and is usually underestimated by a factor of two or more, because the last ten percent — the edge cases, the operational learning, the production surprises — takes as long as the first ninety. Ongoing dual-maintenance cost is the invisible one: migrations rarely fully finish, so the team runs two idioms, two skill sets, and two failure modes simultaneously, often for years. And opportunity cost is the largest: every engineer-month spent re-implementing something that worked is a month not spent on the product. The measurement that settles arguments is simple and almost never computed: what fraction of engineering capacity went to re-implementing existing functionality versus building new capability? Pair it with DORA delivery and stability metrics — if churn were genuinely buying velocity, deploy frequency and change-failure rate would show it.

Q: What does "choose boring technology" actually mean?

It means preferring well-understood technology over novel technology by default, and spending a small, deliberate budget of novelty only where the problem genuinely demands it. Critically, "boring" does not mean old or bad — it means predictable. A boring technology has known failure modes, mature tooling, abundant documentation, a deep hiring pool, and a decade of accumulated answers to the specific error you are about to hit at midnight. Postgres is boring. So are Rails, Django, .NET, Java, and a well-structured monolith. Boring is a compliment about predictability, and predictability is precisely what lets you spend your scarce engineering attention on the problem that is actually yours rather than on operating unfamiliar infrastructure. The central device is the innovation-token framing popularised by Dan McKinley: you get roughly three innovation tokens, where spending one means adopting something your team does not already deeply understand. Three is not a literal quota — it is a discipline that forces the question "is this where our novelty budget belongs?" on every adoption decision, rather than letting each choice be evaluated in isolation as though it had no aggregate cost. Where should tokens go? On your genuine differentiator, or on a constraint the boring option cannot meet — a CRDT layer if you are building real-time collaboration, a specialised serving stack if inference at scale is your business. What almost never earns a token: your CRUD admin panel, your job queue, your primary datastore, your CI system. Those are solved problems, and solving them again in a novel way is how a team ends up with genuinely interesting infrastructure and an unremarkable product.

Q: How do I evaluate whether to adopt a new technology?

Five questions, and a proposal that cannot answer all five is not ready regardless of how compelling the technology is. First: does this solve a problem we actually have? The most common adoption failure is choosing something that is better in the abstract for a problem the team does not have — the technology may be genuinely superior and still be irrelevant to you. Second: can our current stack solve this, even awkwardly? An awkward solution in a tool your team operates confidently usually beats an elegant solution in a tool you do not, because the awkwardness is a known, bounded cost while unfamiliarity is an unbounded one. Third: can we operate it at 3 a.m.? This is the question teams skip most often and regret most. Every new datastore, runtime, queue, or orchestrator is a new failure mode that your on-call engineer must diagnose under pressure with incomplete information. If nobody on the team can debug it when it breaks at the worst time, you have not adopted it — you have deferred an incident. Fourth: who maintains it in two years? Hiring pool depth, ecosystem health, maintainer bus factor, and release cadence are architecture inputs, not soft concerns; a technology maintained by one person is a dependency on that person. Fifth: what is the exit? A technology you cannot realistically migrate off is a permanent decision made with temporary information, which is a bad trade at any level of current enthusiasm. Two process requirements complete it: any adoption needs an operability plan and on-call training before it reaches production, and the decision needs an architecture decision record recording context, options, decision, and consequences — without which the choice has no defenders and will be overturned in three years.

Q: Why are big-bang rewrites so risky?

Because a working codebase encodes years of hard-won knowledge that exists nowhere else, and a rewrite discards all of it, rediscovering it one production incident at a time. What looks like mess in a mature codebase is frequently accumulated correctness: the odd conditional handling the customer whose data is malformed in a specific way, the retry that exists because a partner API becomes unreliable on a particular schedule, the validation that seems paranoid until you learn which incident prompted it. None of this is documented — it was added in response to a bug, often years ago, by someone who has left. A rewrite starts from the specification, which describes what the system was supposed to do, not the accumulated set of things it learned it also had to do. The predictable result is a cleaner system that fails in all the ways the old one had already stopped failing. Layered on top: rewrites systematically underestimate scope because the specification is incomplete by construction, they run alongside the old system for far longer than planned, and they frequently never fully finish, leaving the organisation permanently maintaining both. The alternative is incremental replacement — the strangler fig pattern, where new functionality is built alongside the old system and traffic is progressively migrated component by component, with the old code deleted only once the new path has proven itself in production. This is slower to start and dramatically safer, because at every point you have a working system, the accumulated edge-case knowledge is either preserved or explicitly re-derived one component at a time, and you can stop partway with a coherent result. The same reasoning governs data migrations, where expand-contract patterns exist precisely so you are never in a state that cannot be rolled back.

Q: How does AI-assisted coding change technology choice?

In two opposite directions, and both are worth accounting for explicitly. First, it makes churn cheaper to propose and no cheaper to complete. When an assistant can scaffold a migration to a new framework in an afternoon and produce a working-looking prototype, the proposal cost of a rewrite collapses — but the completion cost does not, because completion is testing, edge cases, operational learning, and the long tail of production surprises, none of which the prototype touched. This is the same asymmetry as the broader verification bottleneck: generation capacity is effectively unlimited while absorption capacity is not. The practical consequence is that you should expect more migration proposals arriving with plausible demos attached, and you should hold them to exactly the same five questions you would apply to a proposal with no demo — a working prototype answers "can this be built" and says nothing about "should we own this." Second, and pulling the other way, mainstream choices now compound harder than they used to. Models write React, Postgres, Python, and other high-corpus technologies substantially better than they write niche frameworks, simply because the training data is vastly larger. That is a real and newly measurable advantage for boring technology: choosing the fashionable-but-obscure option now also costs you AI assistance quality, and that cost shows up continuously as more correction on every generated diff rather than as a one-time learning expense. It is not decisive on its own — if a niche tool is genuinely the right fit, it remains the right fit — but it is a genuine thumb on the scale toward the well-trodden path, and it did not exist three years ago. Net: the innovation budget should be, if anything, slightly tighter than before, and the discipline around evaluating proposals slightly firmer.

Q: What is an architecture decision record and why does it matter so much?

An architecture decision record is a short document — often a single page — capturing the context of a significant technical choice, the options considered, the decision made, and its consequences. It matters far more than its modest cost suggests because undocumented decisions have no defenders, and choices with no defenders get overturned on aesthetics. Consider the failure mode it prevents. A team chooses a technology for good reasons: a specific constraint, a particular operational requirement, an integration that mattered at the time. Nobody writes it down. Three years later the original decision-makers have moved on, a new senior engineer arrives, encounters an unfashionable tool, finds no justification for it anywhere, and reasonably concludes it was an accident of history worth correcting. A migration is proposed and approved because nobody can articulate why the current choice exists. The replacement is also undocumented, and the cycle repeats. An ADR converts "this is old and nobody knows why we use it" into "here is the constraint it was solving — has that constraint changed?", which is a question with an actual answer, and quite often the answer is that the constraint still holds. What makes them work in practice: keep them short (a page, not a design document), write them at decision time rather than retrospectively, store them in the repository alongside the code so they are found by people reading that code, number them sequentially, and never edit a decided ADR — supersede it with a new one that references the old, so the history of reasoning is preserved. The discipline costs perhaps twenty minutes per significant decision and is the single highest-return artefact available against stack churn, because it is the only thing that gives a good decision the ability to defend itself after its authors have gone.

Q: Isn't "boring technology" just an excuse to avoid modernising?

It can be misused that way, and the failure mode is real — but the framework explicitly guards against it, because refusing to spend the innovation budget is treated as its own failure rather than as virtue. The genuine risk of over-conservatism: teams that declined to adopt containers, managed cloud services, or modern CI eventually paid far more than migration would have cost, because the ecosystem moved on and they found themselves maintaining bespoke internal solutions to problems the industry had commoditised — carrying the full cost of building and operating something they could have consumed. That is not prudence, it is a slow-motion expense that shows up as a permanently larger infrastructure team. The distinction the framework draws is between novelty and value. The question is never "is this new?" but "does this solve a problem we have that our current stack cannot solve acceptably?" A technology can be five years old and still be the right adoption if it addresses a real constraint; a technology can be three weeks old and correct if it is genuinely your differentiator. Equally, the framework prescribes spending the budget, not hoarding it — teams should be able to name the two or three places they are deliberately being novel this year, and a team that names zero is probably calcifying. Two practical safeguards against ossification: reallocate the innovation budget annually as an explicit exercise rather than letting it lapse, and periodically ask whether anything you build and operate internally has become a commodity you should now consume. The honest summary is that both failure modes are common and both are expensive: churning constantly wastes capacity on re-implementation, and never changing wastes capacity maintaining what the market now gives away. The discipline is deliberate allocation, and the written rationale is what makes either direction defensible.

Q: How do I measure whether stack churn is hurting my team?

Compute the fraction of engineering capacity spent re-implementing existing functionality versus building new capability, and pair it with delivery and stability metrics — most teams have never measured the first number, and it is usually startling when they do. The primary metric: over the last two to four quarters, categorise engineering effort into new capability (functionality the business did not previously have), maintenance and support (keeping existing functionality working), and re-implementation (rebuilding existing functionality in a new technology or idiom). That third bucket is the churn number. It will not be zero in a healthy organisation — some re-implementation is genuinely warranted — but when it is a large share of capacity and cannot be tied to customer-visible outcomes, the argument about whether churn is a problem is over. The corroborating metrics come from DORA: deploy frequency, lead time for change, change-failure rate, and time to restore. The reason these matter is that migrations are almost always justified as velocity investments — "this will let us move faster" — which is a testable claim. If churn were buying speed, deploy frequency and lead time would improve after each migration completes. When they do not, or when change-failure rate rises because the team is operating unfamiliar technology, the claimed benefit is not materialising. Two secondary signals worth watching: the number of migrations currently in flight simultaneously (more than one is a warning, and unfinished overlapping migrations are the classic symptom), and how many significant technologies in production have no written rationale, since that count predicts future churn directly. Presenting these numbers changes the conversation from a debate about taste — where the person most enthusiastic about the new thing usually wins — into a discussion about allocation, where the trade-off is visible and the business can weigh it.

Satyam Kumar

Back to Blog

ai-architecture

Stack Churn Is Eating Your Roadmap: A Decision Framework for Choosing Technology That Lasts

By Satyam KumarJuly 27, 202612 min read

technology choice boring technology architecture decisions stack churn technical debt adr engineering leadership cto rewrite strangler fig dora metrics innovation budget software architecture legacy modernization engineering strategy 2026

Stack Churn Is Eating Your Roadmap: A Decision Framework for Choosing Technology That Lasts

Frequently Asked Questions

Share this article

Twitter LinkedIn WhatsApp

Satyam Kumar

Founder & AI Architect, AppScale LLP

AI & Cloud Architect. Helping teams build systems that scale to millions.

LinkedIn GitHub

Stack Churn Is Eating Your Roadmap: A Decision Framework for Choosing Technology That Lasts

Frequently Asked Questions

Share this article

Comments

Leave a comment