A year ago I was running a side project on a stack I'd describe as "modern": a React frontend with a Node/Express API, a PostgreSQL database, Redis for caching, Docker Compose for local dev, and a CI/CD pipeline wired to a cloud provider. It worked. It also took me an entire evening to get a new contributor onboarded.
That evening made me ask a question I hadn't thought to ask before: is all of this complexity earning its keep?
The hidden cost of capability
Every tool in a stack has a learning curve, a failure mode, and a maintenance surface. A framework that saves you two days building auth adds a dependency you'll patch for years. This isn't an argument against frameworks — it's an argument for being honest about the tradeoff.
The projects where I felt most productive weren't the ones with the best tooling. They were the ones where I understood every layer of what was happening. When something broke, I knew where to look. When I wanted to add something, I knew where it fit.
"The best tool is the one you understand well enough to bend."
What I actually removed
Over six months I stripped the project back significantly:
- Dropped Redis — the cache hit rate didn't justify the operational overhead
- Replaced the React SPA with server-rendered HTML for pages that didn't need interactivity
- Collapsed the API layer into the same process as the renderer
- Switched from Docker Compose to a single
make devcommand that just works
The result was a codebase half the size, with no measurable regression in user-facing performance. Deploys went from 4 minutes to 45 seconds. New contributors were productive in under an hour.
Minimalism isn't about being clever
The instinct, when you remove things, is to feel like you're leaving capability on the table. But I've come to think of it differently: a minimal stack isn't less capable, it's more legible. You can reason about it. You can hold it in your head.
This doesn't mean avoiding complexity everywhere — some problems genuinely need distributed systems, caches, and queues. But most side projects, internal tools, and early-stage products don't. They need something that works, that you can fix at midnight, and that a new person can understand in an afternoon.
That's the stack I'm building on now. It's quieter. I like it better.