Stack decisions get made emotionally more often than anyone admits: a technology someone enjoyed on their last project, a language that is currently fashionable, a framework a conference talk made look effortless. These choices are expensive and long-lived, so it is worth having a framework for making them deliberately.
Start with the constraints, not the candidates
Five questions narrow the field faster than any comparison table.
- What kind of product is it? A content-heavy site, a real-time collaborative tool, a data-processing pipeline and a transactional line-of-business application have genuinely different needs.
- Who will maintain it? The best stack for a team that knows it well beats a theoretically better stack they will learn on your budget.
- What is the timeline? A tight launch favours mature ecosystems with batteries included over assembling best-of-breed parts.
- What must it integrate with? Existing systems, identity providers and payment or compliance requirements often eliminate options outright.
- What scale is realistic? Not the aspirational number — the one supported by the plan.
The frontend
React remains the pragmatic default for application-style interfaces, largely because of ecosystem depth and hiring availability. Frameworks built on it handle routing, rendering strategy and data fetching so you are not assembling those yourself. Vue and Svelte are excellent and often more pleasant to work in; the trade-off is a smaller hiring pool and fewer third-party components. For content-led sites where search visibility is the priority, server rendering or static generation matters far more than which library you picked.
The backend
Node.js suits I/O-heavy APIs and real-time features, and lets one team work across the whole stack in one language. Python is the obvious choice when data processing, machine learning or scientific work is central. Go earns its place for high-throughput services and infrastructure tooling. Java and .NET remain strong for large enterprise systems with long lifespans, deep tooling and established security practice. Any of these will handle far more load than most products ever generate — the decision should rest on your team and your ecosystem needs, not on benchmark charts.
Boring technology is a competitive advantage. Every unusual choice spends innovation budget you would rather spend on the product itself.
The database
Start relational unless you have a specific reason not to. PostgreSQL in particular now covers JSON documents, full-text search, geospatial data and analytical queries competently, which means one well-understood system often replaces three. Reach for a document store when the data really is schema-flexible aggregates, a key-value store for caching and sessions, a search engine when search is a core feature, and a time-series store for metrics at volume. Most products need one primary database and a cache — not five engines.
Infrastructure
The meaningful choice is less about which cloud provider and more about how much operational responsibility you want. Managed platforms and serverless functions minimise the operations burden and suit small teams and variable traffic. Containers with an orchestrator give you control and portability at the cost of needing someone who understands them. Traditional virtual machines still make sense for predictable workloads and straightforward compliance stories. Pick the least operational overhead that meets your requirements.
Red flags in a stack decision
Be cautious when a technology is chosen because it is new rather than because it fits; when nobody on the team has run it in production; when the community is small enough that you will be debugging the framework itself; when the licence could change under you; or when you are adopting several unfamiliar technologies at once. One new thing per project is a healthy limit.
Write the decision down
Whatever you choose, record what you picked, what you considered, and why — a short architecture decision record is enough. In eighteen months, when someone asks why the project is on this database, that page prevents an expensive re-litigation of a decision that was made for good reasons everyone has since forgotten.