The Cost Shows Up Late, Not Early
Nearly every wrong tech stack decision looks fine for the first few months. The framework ships features quickly, the team is productive, and nobody questions the choice. The real cost shows up eighteen months in, when the thing that made the stack easy to start with — a lack of structure, a framework that hides complexity, a database chosen for convenience rather than access patterns — becomes the thing blocking the next six features.
Three Questions We Ask Before Recommending a Stack
We’ve stopped asking clients what stack they want and started asking what the product needs to be true in three years.
- What will the team actually be able to hire for and maintain, not just what’s exciting to build with today?
- Where will this system actually be under load — reads, writes, or both — and does the data layer match that?
- What’s the cost of being wrong: can this be replatformed in a quarter, or is it a foundation you’re stuck with for years?
When a Rebuild Is Actually the Right Call
Not every wrong stack decision needs an immediate rebuild. Sometimes the right move is isolating the pain point and replatforming just that piece, buying years of runway on the rest of the system. We’ll tell a client honestly when a full rebuild isn’t worth it yet — the goal is the right call for the business, not the most interesting engineering problem.