Choosing a tech stack for your software: what matters and what does not
The stack is the technology your software is built on. Six criteria that should decide it, three that usually do and should not, and our choice.
The short answer
A tech stack is the set of technologies your software is built on: the programming language, the framework, the database, the hosting and the services around them. It decides who can maintain the software in five years, what it costs to run, how securely it behaves and how easily it grows. Six criteria should decide it. Three things usually do decide it and should not: fashion, what the first developer happened to know, and what a vendor is promoting. We choose a small, mainstream, typed stack and change it rarely, because novelty is a cost the client keeps paying long after the developer has moved on.
The six criteria that should decide it
| Criterion | The question | What good looks like |
|---|---|---|
| Fit for the problem | Does this stack suit what the software does? | A content site is not built like a real-time trading system, and the other way round |
| Maintainability over years | Will this be upgradeable and understandable in five years? | Mainstream, typed, tested, documented, with a slow and stable release history |
| Availability of developers | Can another competent team take this over? | Widely used languages and frameworks with large communities |
| Running cost | What does it cost to host and operate at your scale and at ten times it? | Static where possible, managed services, no idle servers |
| Security posture | How does the stack behave by default? | Safe defaults, maintained dependencies, a small attack surface |
| Boring and well supported | Is each piece proven, maintained and unexciting? | Long track records, clear upgrade paths, no single-company lock-in on the core |
The three that decide it and should not
- Fashion. A framework everyone is discussing this year may be abandoned in three. Your software must outlive the conversation.
- What the first developer knew. Convenient for the first build, a problem for every developer after. Ask why the stack fits your problem, not the builder’s history.
- Vendor promotion. Platforms and clouds push their own tools with credits and demos. Some are excellent; the test is whether you could leave, and at what cost.
What we choose, and why
For websites: Astro with TypeScript and Tailwind, built to static files, served from an edge network, with serverless functions for the dynamic parts. For software: TypeScript throughout, a relational database, a mainstream framework, managed hosting, everything in the client’s accounts. The pattern is the same in both: few pieces, all mainstream, all typed, all replaceable individually. We add a new technology to the stack rarely, after it has proven itself elsewhere, and we say so when we do.
What this means for you
You do not need to judge frameworks. You need the six criteria answered in plain language by whoever proposes the stack: fit, maintainability, developer availability, running cost, security, and how boring each piece is. Be wary of fashion, of a builder’s personal history and of vendor incentives. The stack you want is the one that will still be easy to hire for, cheap to run and safe to change long after this year’s favourite has been forgotten.
Frequently asked questions
Should we care about the stack at all, or leave it to the developer?
You should care about the six criteria and ask the developer to explain their choice against them. You do not need to judge frameworks. You do need to know that the stack is mainstream, that other developers could take it over, what it costs to run, and that it is typed and tested. Those answers are yours to demand.
What is the risk of a trendy stack?
That in three years it is abandoned, unfashionable or has changed so much that upgrading is a rewrite. Developers move on; the client is left with software nobody wants to maintain. Boring, widely adopted technology with a long track record ages far better.
Can we change the stack later?
Parts of it, at a cost. Databases and hosting can be moved; a framework change is closer to a rebuild. That is why the decision deserves care at the start and why we favour choices that stay viable for a decade rather than the newest option.