Choosing a technology stack that outlives its author

Technology choice for a business application is a maintenance decision disguised as a technical one. The code will be written once and maintained for a decade.

The criteria that actually predict cost

Can you hire for it? Search your local market and your remote market. If a stack returns a handful of candidates, every future change depends on finding one of them.

Is it boring? Boring means well understood, widely deployed, thoroughly documented, with its failure modes known. Boring is a compliment.

Who maintains it? A foundation or a large company with a support policy is a different proposition from one enthusiast. Check the release history and whether security patches arrive promptly.

What is the support window? Every framework has a version end-of-life date. That date is when your upgrade becomes mandatory, and it should be in your plan before you start.

How large is the dependency tree? Every package is something to update and something that could carry a vulnerability. Fewer, better-chosen dependencies age far better.

The trap of the exciting choice

New frameworks are genuinely enjoyable and often technically superior. They are also where a stack goes to be abandoned. A tool with a small community and one maintainer may be excellent today and unmaintained in three years, at which point your working application becomes a rewrite.

For internal business software, choose the option with the largest community that meets the requirement. Save novelty for things you can afford to throw away.

Practical defaults

• A mainstream language with long-term support releases
• A framework in wide commercial use, not just wide discussion
• A relational database unless you have a specific reason otherwise
• Deployment that a competent engineer can understand from documentation alone
• As few moving parts as the problem genuinely requires

Write down the decision

One page: what was chosen, what was rejected, and why. When someone asks in four years why the system is built this way, that page prevents an expensive rewrite argued from ignorance.

We make these choices deliberately in software development projects.