A business commissioning software is asked, or told, what it will be built with. The reasoning offered is technical: this framework is faster, this language is more modern, this database scales better.
Almost none of that will matter to the business. At the scale of a line-of-business application, every mainstream option is fast enough, and the performance differences that appear in benchmarks are dominated by how the application is written and how the database is queried.
What will matter, repeatedly, over the ten years the system is in use, is duller: how long the platform receives security updates, how easily someone can be hired to work on it, and how much of the system depends on decisions that cannot be reversed.
Support lifecycle, first
Every runtime, framework and database has a support timeline, and when a version reaches the end of it, the business has a system running unpatched software — the same problem as an end-of-life operating system, in a component that is usually less visible.
The Node.js project states the position plainly: production applications should only use Active LTS or Maintenance LTS releases. Its release pattern is worth understanding, because it is representative. Odd-numbered releases historically became unsupported after six months, while even-numbered releases moved into long-term support; from Node.js 27 the model moves to a six-month Current phase with LTS releases guaranteeing critical bug fixes for thirty months in total, on an annual cycle.
The practical points generalise to any stack.
- Never begin a project on a release that is not in long-term support. It is not a head start; it is starting with less remaining life than the alternative.
- Know the end-of-life date of every major component before committing, and record it where infrastructure lifecycle dates are recorded.
- Budget for version upgrades as recurring work rather than as a project that will be justified separately. Software that is never upgraded becomes software that cannot be upgraded, because the gap grows faster than the effort to close it.
- Prefer components with predictable, published schedules over those whose support depends on a single maintainer's continued interest.
The hiring question, which is the real constraint
A stack that one person in the business understands is a stack the business does not control. That is true regardless of the technical merits, and it is the risk that actually materialises.
The relevant question is not whether a technology is good. It is how many people could be hired, locally or remotely, at a realistic rate, who could pick up this codebase and be productive. Mainstream, boring choices win this decisively, and it is the correct criterion for a business rather than a compromise.
| Question | A good answer looks like |
|---|---|
| How long is this version supported? | A published date, not an estimate |
| How many people could we hire for this? | Many, at ordinary rates |
| What happens if the supplier disappears? | Another supplier could take it on |
| Is anything here unusual? | Nothing, or a specific justified reason |
| Who else runs this stack? | Widely used for this kind of application |
| What is the upgrade path? | Documented, incremental, regularly exercised |
The fourth row is worth pressing on. Novelty in a business application is a cost with no corresponding benefit. An unusual framework, a niche database, or a language chosen because the developer wanted to learn it all produce the same outcome: a system only its author can maintain.
What is reversible and what is not
Stack decisions are not equally weighty, and treating them as though they are wastes deliberation on the ones that do not matter.
| Decision | Reversibility | Implication |
|---|---|---|
| Frontend framework | Moderate — rewrite the interface | Do not over-deliberate |
| Backend language and framework | Low — effectively a rewrite | Deliberate properly |
| Database engine | Very low — data and queries both move | The most consequential single choice |
| Hosting platform | Moderate, if not deeply coupled | Avoid proprietary services in core logic |
| Authentication provider | Low — every user and permission moves | Choose something durable |
| Background job system | High | Change freely later |
The database row is the most important line in this article. Data outlives applications. A business will replace its application, possibly more than once, while continuing to hold the same customers, orders and history. A mainstream, well-documented relational database with a long support horizon is the durable choice, and exotic data stores in a business application should be justified against a specific requirement rather than adopted as a default.
The hosting row carries a related warning. Building core business logic on a proprietary managed service couples the application to one provider in a way that is invisible until the provider changes its pricing or its terms. Using managed services is sensible; putting logic that only exists there into the centre of the system is a decision to make deliberately.
The parts of the stack nobody asks about
Stack conversations cover language, framework and database. Several components that determine day-to-day operability are usually not discussed at all.
- How it is deployed. Manual deployment produces environment drift and defects that only appear in production. Automated deployment is a stack decision.
- How it is configured. Configuration in files edited by hand cannot be reproduced; configuration from environment produces environments that match.
- How secrets are handled. Credentials in the repository or in configuration files are credentials with no expiry and no audit trail.
- How it is observed. An application with no metrics or structured logging is one whose problems are reported by users.
- How dependencies are updated. A project with a hundred libraries has a hundred sources of vulnerabilities, and something must tell you when one is announced.
The last is worth a specific question to any supplier. Modern applications carry large dependency trees, and vulnerabilities are announced against those dependencies continuously. Whether anything watches for that, and who acts on it, is part of the stack rather than an operational afterthought.
A defensible default
For a typical business application — a portal, an internal system, a CRM — a stack chosen on these criteria will be unremarkable, and that is the point.
- A mainstream backend language on a long-term-support release, with a widely used framework.
- A mainstream relational database, on a version with years of support remaining.
- Containerised, so the environment is reproducible and the hosting choice stays loose.
- Automated deployment, configuration from environment, secrets from a secret store.
- Metrics and structured logs from day one.
- Automated dependency vulnerability alerting, with a named owner.
None of that is interesting, and a supplier proposing it is not being unambitious. It is the configuration most likely to still be maintainable, hireable and patched in eight years, which is the only property that matters for the whole of the system's life.
Does the choice of programming language affect performance meaningfully?
For a typical line-of-business application, rarely. At that scale every mainstream option is fast enough, and real-world performance is dominated by how the application is written and how the database is queried rather than by the language. Performance becomes a genuine selection criterion only for specific workload characteristics, and those should be identified explicitly rather than assumed.
What is the most consequential stack decision?
The database engine, because it is the least reversible. Data outlives applications — a business will replace its application, possibly more than once, while continuing to hold the same customers, orders and history — and changing engines means moving both the data and every query written against it. A mainstream relational database with a long support horizon is the durable default, and anything exotic should be justified against a specific requirement.
Should software be built on the newest version of a framework?
No — on the current long-term support release. The Node.js project states the general position directly: production applications should only use Active LTS or Maintenance LTS releases. Beginning on a version outside long-term support is not a head start, it is starting with less remaining supported life than the alternative, and it brings the first forced upgrade closer.
Why does the hiring pool matter more than technical merit?
Because a stack that one person understands is a stack the business does not control, and that risk materialises far more often than a performance limitation does. The useful question is how many people could be hired, at ordinary rates, who could become productive on this codebase. Mainstream choices win that decisively, and novelty in a business application is a cost with no corresponding benefit.
What should be asked about a proposed stack that usually is not?
How it is deployed, how it is configured, how secrets are stored, how it is observed, and how dependency vulnerabilities are detected and acted on. These determine day-to-day operability and are rarely part of a stack conversation. The dependency question is particularly worth pressing: modern applications carry large dependency trees with vulnerabilities announced continuously, and whether anything watches for them — and who acts — is part of the stack rather than an afterthought.
Sources and further reading
- How a custom CRM actually gets built— where this decision sits in the project
- Building scalable business applications— the architecture decisions this stack has to support
- Custom software vs SaaS— whether to be making this decision at all
- Secrets management for business systems— the secret store named in the default stack
- API integration for modern businesses— the contracts this application will need to honour
- Linux servers for business— the same lifecycle discipline applied one layer down
- Node.js releases and LTS policy— the production guidance and release pattern cited above; check the current table before committing
- endoflife.date— aggregated lifecycle dates across runtimes, frameworks and databases; confirm against the vendor before relying on a date
- The Twelve-Factor App— configuration from environment, and the operational properties in the default stack
Services This Relates To
Written by KYCONNECTS Engineering. Client names are withheld under confidentiality.