When to Stop Adding Tools to the Stack

Every year, a new AI tool promises to replace the one I used last year. Every month, a new framework promises to solve the problem my current stack already solves. The temptation to keep adding is constant. The discipline to stop is what actually ships work.

The Cost Curve That Is Never Shown

A new tool has an obvious cost: the learning hours. It has a hidden cost: the maintenance hours forever after. Every tool in the stack is a thing I must keep current, keep documented, keep tested, and keep explainable to the next person. The hidden cost is often 5x the obvious one.

When I add a tool, I am committing to those costs for the life of the codebase. That is a serious commitment. I treat it as one.

The Three Questions Before Adopting

Does it replace something? Or does it add a layer? Replacement is usually fine. Addition almost never is. A new ORM that replaces Prisma is a real evaluation. A new cache layer on top of Prisma is usually a smell.

Will I use it weekly, or on one project? Weekly use compounds. One-project use evaporates and leaves a maintenance burden. If I cannot name three upcoming projects where it fits, I skip it.

What does it cost to remove later? If the answer is 'rewrite the app', the tool is not a tool, it is a marriage. Marriages deserve more scrutiny than weekly deps.

A Stack Audit Every Quarter

plaintext

For each tool in the stack:
  - last time I used it: <date>
  - monthly maintenance cost: <low/med/high>
  - would I choose it again today: <yes/no>
  - if no: plan to remove within 90 days

Every quarter I kill one tool. Not add one. Kill one. Subtractive quarters keep the stack from bloating into unmaintainability. See Subtraction as Design for the cognitive research behind why we instinctively add instead of remove.

The Payoff

My stack in November 2025 is smaller than it was in April 2025. Not because I did less work, because I did more work with fewer tools. That is the goal: more shipped, less surface area to maintain.

Stopping is a skill. Practice it quarterly.

What Fills the Time Instead

Time saved from not learning the new tool goes into shipping with the one I already know. A month spent getting genuinely expert at Lambda is worth more than a month sampling six new serverless platforms. Depth in the chosen tools compounds. Breadth across unused tools decays. Redirect the learning budget from acquisition to mastery, and the shipped output per quarter goes up. That is the counter-intuitive move: the discipline of not learning new things is how I learn to ship faster.