Custom software: build vs buy, done right / Build it well
How to choose a technology stack
Teams love to argue about the newest tools, and the newest tool is rarely the right one. The right technology stack is usually the boring one: well-known, widely used, with a long future and people who can maintain it. Here is how to choose without picking new tools you will regret.
Published July 27, 2026. Editorial.
Key takeaways
- The right stack is usually the boring, proven one your team already knows.
- Choose technology by how easy it is to hire for and maintain, not by how new it is.
- Let the requirements pick the stack, not the other way around.
- Novelty is a cost you pay every year in maintainers you cannot find and bugs nobody has seen.
Ask a room of engineers what to build with and you will get a debate about the newest framework, the trendiest database, the language everyone is excited about this year. The excitement is real and it is a bad guide. The technology you build on decides how easy the software is to run, change, and hire for over its whole life, and those things reward boring, proven choices far more than exciting new ones.
Boring technology is an advantage
A boring technology is one that has been around long enough to be well understood. Its bugs are known and documented. Its community is large, so answers to your problems already exist. Its future is not in doubt, so you are not risking your product on a tool that might be abandoned in two years. Boring is not a compliment engineers like to hear, and it is exactly what you want for software you will run for years.
The newest tool is the opposite on every count. Fewer people know it, so hiring is harder. Its problems are undiscovered, so you find them yourself, in production. Its future is uncertain. You are paying to be an early tester, and that cost lands on you every year, not just at the start. Use new tools only in small, safe parts of the system where being wrong is cheap.
Choose for hiring and maintenance
The most important question about a stack is not "is it fast" or "is it elegant." It is "who will maintain this in three years, and how easily can we find them?" A stack that only one person understands is a liability no matter how clever it is. A stack that thousands of engineers know is safe, because you can always find someone to keep it working well.
This connects directly to total cost of ownership. As we cover in total cost of ownership, most of the money in custom software is spent after launch, on maintenance and change. A hard-to-hire-for stack raises that cost every year. A common stack lowers it. Choosing technology is largely choosing your future maintenance bill.
Let requirements lead
A stack should be chosen to fit the job, not the other way around. This is why requirements come first. When you know what the software actually has to do, the constraints, the scale, the rules it must obey, the sensible technology choices narrow on their own. We cover that first step in how to write software requirements.
Picking the stack before you understand the problem is how teams end up forcing a job into a tool that was never right for it. If your product handles a lot of connected data, that suggests one choice. If it must run offline on a phone, that suggests another. Let the real needs decide the choice, and resist choosing a tool first because someone wanted to use it.
The few things that genuinely matter
Put the arguments aside and a good stack choice depends on a short set of questions. Does the team already know it, or can it learn it fast? Is the community large enough that answers exist when you get stuck? Will it still be supported in five years? Does it fit what the requirements actually demand? Can you hire for it without paying a rare-skill premium? Answer those honestly and the flashy differences between competing tools usually stop mattering.
There is one modern issue worth naming. When AI is part of your product, some stack choices are driven by which tools work well with the models and libraries you depend on. That is a real constraint, and it is its own topic, covered in the building AI products guide and in our AI development work. Even there, the idea that boring is safer still applies to everything around the AI part.
Avoid the failure this prevents
A bad stack choice is one of the quiet causes of custom software failure. It shows up as a system only one person can maintain, or a tool that works poorly for the problem, or a base of code that gets harder to change every month. We collect these patterns in how to avoid custom software failure, and the main guide ties the technology choice back to the larger build decision. Choose boring, choose for maintenance, and let the requirements lead. That is most of a good stack decision.
Common questions
Should I use the newest technology for custom software?
Usually not. The newest tool has fewer people who know it, undiscovered problems, and an uncertain future, and you pay for all three every year. The right stack is usually the boring, proven one that is well understood and easy to hire for.
What is the most important factor in choosing a technology stack?
How easily you can maintain and hire for it over the software's life. Most of the cost of custom software comes after launch, so a stack thousands of engineers know lowers your future bill, while a rare one raises it every year.
Should I pick the technology stack before writing requirements?
No. Let requirements lead. When you know what the software has to do, its scale, and its rules, the sensible technology choices narrow on their own. Picking a tool first is how teams force a job into something that was never right for it.
What is a boring technology stack and why does it matter?
A boring technology stack is one that has been around long enough to be well understood, with known bugs, a large community, and a future that is not in doubt. It matters because most of the cost of custom software comes after launch, and a boring stack is far easier and cheaper to maintain and hire for over that time.
How do I choose a technology stack for a new custom software project?
Start from the requirements, not the tools. Confirm the team already knows the stack or can learn it fast, check that the community is large enough that answers exist when you get stuck, and confirm it will still be supported in several years. Let what the software must do narrow the sensible choices.
Is choosing a newer, less common technology ever worth the risk?
Occasionally, for a small, safe part of the system where being wrong is cheap and the newer tool solves a genuine problem older ones cannot. For the core of a product, the newest tool is rarely worth it, since fewer people know it, its problems are undiscovered, and hiring for it later costs more.
How does the technology stack affect long-term maintenance cost?
Directly. A stack thousands of engineers know is easy to find help for, which keeps the yearly maintenance bill lower. A stack only one person understands is a liability regardless of how well it was built, because losing that person can stop the ability to change or fix the software at all.
Does using AI in a product change how I should choose a technology stack?
It adds one real constraint: some stack choices are driven by which tools work well with the AI models and libraries the product depends on. Outside of that specific AI layer, the same boring-is-safer reasoning still applies to the rest of the stack around it.
More in Build it well
How to write software requirements
Most failed software projects were not failed by bad code. They were failed by a plan nobody could describe clearly. Good requirements are not a giant document. They are a short, honest statement of what the software must do and why, kept current as you learn. Here is how to write them.
How to avoid custom software failure
Custom software rarely fails because of bad luck. It fails from a handful of patterns that repeat across projects: a vague plan, scope that never stops growing, senior decisions handed to junior people, and a demo mistaken for a product. Know the patterns and you can avoid every one of them.