Choosing a Tech Stack: A Decision Framework
Stack arguments usually argue about tools when the real variables are the team, the deadline and the shape of the problem. Decide those first and most of the stack falls out of them.
Start with five constraints
- Who maintains it? The best stack is usually the one your team already knows. A technically superior tool nobody can debug at 2am is a liability.
- What shape is the product? Content site, dashboard, marketplace, data pipeline and real-time application have genuinely different needs.
- How much traffic, realistically? Most projects never exceed what a single modest server handles. Designing for imaginary scale is the most common and most expensive mistake.
- What is the deadline? Short timelines favour batteries-included frameworks and managed services.
- What is the monthly budget? Including the hours someone spends operating it, which is usually larger than the hosting bill.
Stacks that fit common cases
| If you are building… | A reasonable default | Why |
|---|---|---|
| Content or marketing site | Static HTML, Astro, Eleventy or Hugo on a CDN | Fastest possible pages, trivial hosting, almost no attack surface |
| Web app with accounts and payments | Next.js or Remix with Postgres, or Django, or Rails | Mature auth, migrations and admin tooling |
| Internal dashboard | Django admin, Retool-style tooling, or a simple React front end | Speed of delivery outweighs polish |
| Data work | Python with pandas or Polars, scheduled jobs, Postgres or DuckDB | Library ecosystem is unmatched |
| Mobile app | React Native or Flutter; native when hardware features dominate | One codebase covers both stores |
| Real-time features | Node, Elixir or Go with WebSockets | Concurrency models suited to many open connections |
Databases
Start with PostgreSQL unless you have a specific reason not to. It handles relational data, JSON documents, full-text search, geospatial queries and time-series workloads competently, which removes several services from an early architecture. SQLite is genuinely excellent for single-server applications and read-heavy sites. Reach for a specialised store — a document database, a cache, a vector database, a queue — when you can name the specific query pattern Postgres is handling badly.
Hosting
- Static hosting (GitHub Pages, Netlify, Cloudflare Pages, Vercel): free or near-free tiers, global CDN, no servers to patch. Ideal for content sites.
- Platform as a service (Render, Railway, Fly, App Platform): deploy from Git, managed databases, predictable cost.
- Virtual machines: cheapest per unit of compute, most operational work.
- Serverless functions: excellent for spiky, short workloads; awkward for long-running jobs and persistent connections.
Signals that a choice is going wrong
- Setting up a local development environment takes a new person more than a day.
- A one-line copy change requires a deployment of four services.
- Your monthly infrastructure bill is larger than your revenue and traffic is flat.
- You cannot explain, in one paragraph, why each service in the diagram exists.
Rewrites rarely fix these; narrowing scope usually does. Remove a service, merge two repositories, delete the feature nobody uses.
Common questions
Is it bad to choose boring technology?
It is usually the right call. Mature tools have documented failure modes, large hiring pools and answers already written for most problems you will hit.
When is a rewrite justified?
When the current system blocks a change the business genuinely needs and the cost of that blockage, measured over a year, exceeds the rewrite plus the features you will not ship during it.
Keep reading
Deploying a Static Site: From Folder to Live URL
How static hosting works, deploying with GitHub Pages and the main alternatives, connecting a custom domain, HTTPS, and what to check after launch.
APIs Explained: Requests, Auth and Errors
What an API actually is, how HTTP requests and responses work, how authentication is handled, and how to consume an API without fragile code.
Web Performance: What Actually Makes Pages Fast
Core Web Vitals in plain language, the handful of changes that produce most of the speed gain, and how to measure improvement honestly.
Spotted something out of date? Send a correction — guides are revised rather than quietly deleted.