Choosing a Tech Stack You Can Still Live With Next Year

Most stack debates are about preference. The decisions that actually age well are boring: what the team can operate under pressure, what hiring looks like in two years, and how much of the product depends on a library that exactly one person understands.

We often meet products a year or two after those decisions were made. The pattern is familiar: the technology itself is rarely the real problem. The problem is how it was put together, and how much of it only works because a particular person remembers how.

Optimise for the second year, not the first sprint

A framework that ships version one quickly can still be the reason a release takes a week eighteen months later. Before choosing, look at how the product will change: new integrations, more data, more teams touching the same code — and whether the stack keeps those changes cheap.

One B2B SaaS product we worked on had started as a proof of concept and grown feature by feature. The technology choices were sensible — React, Next.js, TypeScript, Node.js, PostgreSQL. What had gone wrong was structure: there were no clear boundaries inside the product, so every new request took longer than the last and nobody could say which areas were safe to change. We didn’t replace the stack. We restructured the code around modules, added tests around the flows customers used every day, and the same technologies started to feel fast again.

Questions worth answering before you commit

• Can the team run it at 2 a.m.? Debugging, monitoring and rolling back matter more than benchmark results.

• Can you hire for it? A niche language may be a pleasure to write, but check how long it takes to find the second and third engineer who knows it.

• How healthy is the ecosystem? Look at release history, maintainers and how breaking changes were handled in the past.

• Is it testable? If part of the system is hard to test automatically, it will be tested less — and it will break more.

• What does it cost to operate? Hosting, licences and the hours spent keeping it running all belong in the comparison.

Leave room to replace parts

Clear boundaries between modules and services matter more than the names on the architecture diagram. When each part can be replaced without rewriting the product, the stack stops being a one-way door and becomes something the team can adjust as the product grows.

That doesn’t mean starting with microservices. For most early products, a well-structured monolith with clear internal modules is easier to build, test and deploy. The boundaries are what matter — you can split along them later if you need to.

Infrastructure is part of the stack

Application code gets most of the attention in stack discussions, but deployment is where many teams feel the pain first. On one SaaS platform the application was in reasonable shape, yet releases were manual, happened late in the evening, and only one engineer knew the full sequence. Describing the environments as code and moving deployments into an automated pipeline with staged rollouts changed the team’s working week more than any framework upgrade could have.

If a stack decision doesn’t cover how the product is built, deployed, monitored and rolled back, it is only half a decision.

Mobile deserves its own conversation

Native, cross-platform or a mix is a real trade-off, and it depends on the product more than on fashion. Heavy use of device features, demanding performance or platform-specific UX push towards Swift and Kotlin. A content-driven app with a small team may be better served by a shared codebase. Whichever way you go, plan for testing on real devices and older OS versions from the start — that is exactly where apps that work fine on the team’s own phones tend to fail.

Write the decision down

A short decision record — what you chose, what else you considered, and why — takes half an hour. A year later it saves the team from re-arguing the same choice and tells new engineers which constraints were real and which have since changed. A stack you can still live with next year is usually one where people remember why it was chosen.