Technology stack decisions are made badly in predictable ways. A CTO chooses a language because they used it at their previous company. A founding engineer picks a framework because it performed well on a benchmark they read. A team adopts a new database because it was trending on a developer forum. Each of these decisions feels defensible in isolation. Collectively, they produce systems that are difficult to hire for, expensive to operate, and fragile under conditions the benchmark never tested.
The right stack for a given team and problem is almost never the most technically sophisticated option. It is the option that the team can hire for, debug at two in the morning, and maintain for five years without a full rewrite. These criteria are boring. They are also the ones that determine whether a system survives contact with production.
We evaluate technology choices across four dimensions: talent density, operational maturity, infrastructure fit, and exit cost.
Talent density measures how many engineers in the relevant hiring market know this technology. A stack that requires senior engineers with rare specialisations creates a permanent hiring constraint that compounds as the team grows. The talent density calculation is local, not global: the availability of Rust engineers in San Francisco is not relevant to a company hiring in Nairobi.
Operational maturity measures how well-understood the failure modes are. A technology with ten years of production usage has known failure modes, documented solutions, and a large community that has encountered and resolved edge cases. A technology that is two years old has none of these. The cost of operating an immature technology is paid in incidents, debugging time, and the absence of prior art when something goes wrong at three in the morning.
Infrastructure fit measures compatibility with the cloud providers, connectivity profiles, and hardware constraints actually available to the organisation. A database that requires consistent low-latency network access is a poor choice for a deployment environment with variable connectivity. A runtime that consumes large amounts of memory is a poor choice for an environment where compute costs are high relative to revenue.
Exit cost measures how difficult it would be to migrate away from this technology if it turns out to be the wrong choice. Technologies with large surface areas, proprietary data formats, or deep framework dependencies are expensive to exit. Technologies built on open standards with clean interfaces are cheaper. Exit cost does not determine the choice, but it should inform the confidence threshold required before making it.
The most consequential stack decision for most product companies is the backend architecture: whether to build a monolith or adopt microservices from the start.
The correct answer for most teams at most stages is the monolith. A well-structured monolith that can be deployed as a single unit, scaled horizontally when needed, and extracted into services when the team and traffic volumes justify it is faster to build, easier to debug, and cheaper to operate than a microservices architecture of equivalent functionality. The microservices architecture becomes the right choice when the monolith has reached the limits of its horizontal scaling, when teams need to deploy independently, or when different components have radically different runtime requirements. These conditions do not exist at founding.
Database selection follows similar logic. PostgreSQL is the correct default for the vast majority of product use cases: it is operationally mature, widely understood, available on every major cloud provider, and capable of handling workloads far beyond what most products will ever encounter. The cases that genuinely require a specialised database are real but rare: time-series data at extreme volume, graph traversals with deep relationship chains, or write throughput that exceeds what a single PostgreSQL instance can handle. These cases exist. They are encountered far less frequently than specialised databases are adopted.
Frontend framework decisions are dominated by talent availability more than any other factor. The engineering hours required to hire, onboard, and make productive an engineer in a mainstream framework are significantly lower than for niche alternatives. The productivity difference between well-understood frameworks is smaller than the hiring advantage of choosing the one your local market knows.
Every technology choice is a bet on a future state: the future load the system will handle, the future team that will maintain it, the future requirements it will need to satisfy. The framework above is designed to make that bet with accurate information rather than enthusiasm.
The best engineering teams we have worked with share a common characteristic: they are deeply familiar with a small number of technologies and deeply suspicious of adopting new ones without a specific, demonstrable need. They are not opposed to new technology. They are opposed to incurring the cost of adoption without a clear return. This discipline produces systems that work reliably, teams that can hire and onboard quickly, and organisations that spend their engineering budget on features rather than infrastructure complexity.
