A technology stack is the languages, frameworks, infrastructure, and other technologies used to build and run a system. Choosing one is a long-term CTO responsibility: production systems may remain in use for decades, and a stack that resists incremental updates can become costly or risky to replace. Choose with the people who will inherit and maintain it in mind. section 8.0
When an old stack becomes a business problem
Modernization work can uncover systems that are 30 to 40 years old, including Cobol applications; one observed system was 46 years old and ran IBM RPG through green-screen terminals. Older systems can carry high running costs, security weaknesses, and limited scalability. Age alone does not tell you what to do next: the cost and risk of changing a critical system also matter. section 8.0
When assessing a stack—especially during acquisition due diligence—ask:
- How different is it from ours, and can our team work with it? section 14.5.1
- Can we recruit engineers and continue supporting its hardware and operating system, if relevant? section 14.5.1
- What could be streamlined, and what would a rewrite cost in effort, money, and disruption? section 14.5.1
Future support is part of the decision, not an afterthought. Languages and frameworks affect hiring and growth; open-source licenses can affect the company. The aim is a stack the organization can keep building on, rather than one that only its original team can manage. section 8.9 section 8.0
