Engineering · 3 min read
Choosing a Tech Stack You Won't Regret
Most stack arguments are conducted as technical questions and settled as social ones. The framework that wins is usually the one the loudest person in the room already knows. That is not the worst way to choose — familiarity is worth a great deal — but it is worth being honest that it is what happened.
The question behind the question
“Which framework should we use?” is almost never the real question. The real question is some version of: who will be maintaining this in three years, what will they need to know, and how quickly can someone who has never seen this code make a small change safely?
Framed that way, a lot of the usual comparison points stop mattering. Benchmark differences between mainstream frameworks are rounding errors next to the cost of a rewrite forced by a maintenance dead end. Very few products fail because the framework was too slow. A great many struggle because the only person who understood the architecture left.
Boring technology is a feature
A technology that has been in wide use for years has a property nothing new can offer: its failure modes are known. When something breaks at an inconvenient hour, the error message has been pasted into a public forum by someone else already, and the answer is underneath it.
That is worth more than it sounds. The cost of a young, elegant tool is rarely visible on the day you adopt it. It shows up later, in the hours spent discovering that a problem is a bug in the library rather than a mistake in your own code.
This is not an argument against ever adopting anything new. It is an argument for spending your novelty budget deliberately. Pick the one or two places where a newer tool genuinely changes what you can build, and be conventional everywhere else.
What actually locks you in
Teams worry about lock-in at the wrong layer. Swapping a UI framework is expensive but tractable — it is mostly mechanical work, and the boundaries are visible. The things that are genuinely hard to reverse are quieter:
- Your data model. Schemas outlive the applications written against them. A shape that made sense for the first feature can constrain every feature after it.
- Anything holding customer state. Auth providers, payment processors, and anything storing records you are legally obliged to keep are all far harder to leave than to join.
- Assumptions baked into the architecture. Whether requests are synchronous, whether a job can be retried safely, whether two users can edit the same thing at once. These are rarely written down and expensive to change later.
Spend your design attention there. The framework can be changed by a determined team in a quarter; the data model cannot.
Hiring is part of the stack
A stack is also a statement about who you can hire, how long onboarding takes, and what happens when someone is unavailable. A choice that only two people on earth are fluent in is a staffing risk, whatever its merits.
This cuts both ways. A mainstream stack has a deep hiring pool and a shallow average level of specialism. A niche one has the opposite. Neither is wrong — but the decision should be made with the hiring consequence in view rather than discovered eighteen months later.
How we decide
In practice we work through a short list of questions, roughly in this order:
- What does this product actually have to do that is unusual? Most have nothing, and that is good news — it means the conventional answer is available.
- Who maintains it after launch: an in-house team, us, or someone not yet hired? The answer changes the calculation entirely.
- What is the smallest set of moving parts that covers the requirement? Every service, queue, and database is something that can fail independently and has to be understood by whoever is on call.
- Where is the one place a newer tool is genuinely worth the risk, and can we contain it behind an interface if it does not work out?
None of this produces a single correct stack, and anyone claiming otherwise is selling something. It produces a defensible one — a choice you can explain to the team inheriting it, which is a better test than any benchmark.
Build Software That Grows Your Business
From custom software development and AI automation to cloud-native applications, we create secure, scalable solutions built for long-term success.
Get Free Consultation