Summer Stack Audit: What Stayed and What Left

Every quarter I walk through my stack and ask one question per tool: is this earning its place? Not 'does it work.' That is a low bar. Earning means the benefit justifies the complexity. Three tools failed that test this quarter.

What Stayed

FastAPI, DynamoDB, Next.js, Vercel, SES, Claude Code. These are my load-bearing dependencies. Each one solves a problem I would otherwise rebuild badly. I renewed their membership without debate.

What Left

Redis: I added it early for caching, then realized DynamoDB with a TTL attribute covered 90% of the use cases at $0/month. Redis stayed around as dead weight for a month. It is gone now.

A custom logger library: I wrote a wrapper around logging for structured JSON output. Then I found structlog, which does it better and has a real community. My wrapper is deleted.

One of two test runners: I had pytest for backend and Jest for frontend, plus Playwright for e2e. Keeping three runners meant three configs, three flaky-test cultures, three CI steps. I dropped Jest in favor of Vitest and standardized on the Jest-compatible API across frontend and e2e. One less thing.

The Audit Question Set

For each dependency:
  - When did I add it?
  - What was the alternative?
  - Is the alternative now acceptable?
  - What breaks if I remove it?
  - How long to remove it?

Most tools pass this. The ones that fail are usually things I added 'just in case' and never stress-tested. Those are the easy wins.

The Discipline

Quarterly audits are cheap if you do them. Yearly audits are expensive because you have accumulated a year of rationalizations. I put a recurring calendar block for this now. The half-hour I spend prevents months of drag.

See the Well-Architected Framework operational excellence pillar for the broader discipline. Audit small, audit often.