Free Tool
Tech Stack Selector
Every stack choice has one constraint that decides it.
Not a quiz. Tables you can read in two minutes, organised by the question that actually settles each decision.
The decision tables
These reflect what we actually build in. Where a choice we do not staff is the better answer, the table says so rather than steering you to us.
Frontend — decided by whether you need SEO and server rendering
| Choose | When | Watch out for |
|---|---|---|
| Next.js (App Router) | Content or marketing matters, SEO is an acquisition channel, or first-load speed is competitive | The caching model punishes guesswork; needs someone who has run it in production |
| React SPA (Vite) | Behind a login, no SEO requirement, app-like interaction | You own routing, data fetching, and code splitting yourself |
| A CMS (WordPress, Webflow) | Content-led marketing site with no application behaviour | Do not grow it into an application; that is how the expensive rebuilds start |
Mobile — decided by your existing team and how custom the interface is
| Choose | When | Watch out for |
|---|---|---|
| React Native | You already have React engineers, or web and mobile share business logic | Anything the framework does not wrap needs a native module written twice |
| Flutter | The interface is heavily custom and animation quality is part of the product | A smaller senior Dart pool; hiring later takes longer |
| Native (Swift / Kotlin) | Games, heavy AR, or the core value is a platform-exclusive capability | Roughly double the cost and two codebases to maintain |
| No app at all | Users would not open it weekly — a responsive site converts as well | Saves $20,000–$35,000 and an annual maintenance line |
Backend — decided by whether the workload is concurrency or data-processing bound
| Choose | When | Watch out for |
|---|---|---|
| Node.js + TypeScript | Many concurrent connections, real-time features, shared types with a TS frontend | CPU-heavy work blocks the event loop; move it to a queue or another runtime |
| Python (FastAPI) | Data processing, ML, scientific work, or heavy integration and scripting | Less suited to very high concurrency; typed and tested Python is not the default |
| Managed backend (Supabase, Firebase) | Early validation, small team, standard CRUD and auth | Costs and lock-in rise with scale; plan the exit before you need it |
Database — decided by whether your data is genuinely relational
| Choose | When | Watch out for |
|---|---|---|
| PostgreSQL | Relationships, constraints, reporting, or multi-row transactions matter | The default for most products; JSONB covers a lot of document-shaped needs |
| MongoDB | Documents genuinely vary in shape and access is mostly by key | Modelling it like relational tables and joining in code is the classic failure |
| Postgres + pgvector | You need similarity search for AI features | Usually removes the need for a separate vector database entirely |
Hosting — decided by whether traffic is spiky or steady
| Choose | When | Watch out for |
|---|---|---|
| Vercel or similar managed platform | Next.js app, small team, no dedicated infrastructure person | Cost climbs with traffic; worth re-evaluating past a few thousand dollars a month |
| AWS ECS / Fargate | Steady traffic, long-running processes, or platform costs have outgrown the convenience | You now own deployment, monitoring, and cost management |
| Serverless (Lambda) | Spiky, event-driven, short-lived work | At sustained load it typically costs more than an equivalent container |
| Kubernetes | Genuine scale, multiple teams, or a platform requirement | Permanent operational overhead most products under a few million daily requests do not need |
Quick Answer
Updated August 22, 2026
How do you choose a technology stack?
By identifying the one constraint that dominates each decision, rather than comparing feature lists. For the frontend it is whether you need SEO and server rendering. For mobile it is whether you already have a React team and how custom the interface is. For the backend it is whether the workload is concurrency-bound or data-processing-bound. For the database it is whether your data is genuinely relational. For hosting it is whether traffic is spiky or steady. Nearly every stack argument is really a disagreement about which constraint applies, and naming it resolves the argument faster than any comparison table.
Format
5 decision tables
Approach
Constraint-first, not feature lists
No form
Nothing to fill in
Best for
- Founders choosing a stack for a first product
- Teams re-litigating a decision without a framework
- Anyone evaluating a vendor’s proposed stack
Not best for
- Stacks outside what we work in, which we do not cover honestly
- Highly specialised domains like embedded or games
- Replacing a real architecture conversation for a complex system
FAQ
Questions about this tool
Is there a single best stack?
No, but there is a reasonable default for most products: Next.js and TypeScript on the frontend, Node.js on the backend, PostgreSQL for data, and a managed platform for hosting until cost says otherwise. Deviating from that should be a deliberate decision with a named reason.
Should we use the newest technology?
Only where it solves a problem you actually have. New tools cost you in hiring, documentation, and unanswered questions on the internet. Boring technology is a legitimate strategy and usually the right one for a business-critical system.
What if our current stack is wrong?
Rarely worth a rewrite on stack grounds alone. Incremental migration, moving one area at a time, is almost always the lower-risk path for anything a business depends on daily.
Why is Angular, Vue, .NET, Java, or PHP not in these tables?
Because we do not staff them, so we cannot give you a useful opinion. They are all legitimate choices and plenty of good teams build on them. We would rather leave a gap than fill it with something we do not practise.
How much does the stack choice actually matter?
Less than the team and the data model. A good team on a mediocre stack outperforms the reverse consistently. Where stack choice does bite is hiring and long-term maintenance, which is why it is worth a deliberate decision rather than a default.
Related
Go from a number to a plan
The guides behind this tool, and the other free tools alongside it.