How to Choose a Tech Stack

A tech stack is the set of tools you build with: a programming language, a framework, a database, a hosting provider. Picking the right one means your project moves fast. Picking the wrong one means you'll rebuild it in two years.

Most founders overthink this. The truth is simpler: pick something proven, something your team knows or can learn, and something that won't become obsolete in three years.

What goes into a tech stack?

A complete stack has layers:

1. Frontend. What users see and interact with. React, Vue, Svelte.
2. Backend. The server that processes requests, stores data, runs logic. Node.js, Python, Go, Java.
3. Database. Where your data lives. PostgreSQL, MongoDB, Firebase.
4. Hosting. Where the server runs. AWS, Vercel, Railway, Render.
5. Real-time or async jobs. Message queues, webhooks, task runners if you need them.

You don't need to pick all of these. A simple web app might just be a frontend and database. A complex system touches all five.

The boring stack that works

If you're starting out, I recommend:

• Frontend: React or Vue
• Backend: Node.js with Express or Django (Python)
• Database: PostgreSQL
• Hosting: Vercel (for frontend) and Railway or Render (for backend)

This stack is not exciting. It's used by thousands of companies. It has enormous community support, documentation, and tutorials. When you get stuck, you'll find the answer on Stack Overflow.

It's also not expensive to run, scales to significant size before you need to optimise, and you'll find developers who know it.

How to choose your frontend

Your frontend is what users interact with. React and Vue are the dominant choices.

React:

• Most widely used. Biggest community. Easiest to hire developers for.
• Steeper learning curve if you're new to JavaScript.
• More boilerplate to write, but you have more control.
• Use if: you're building something complex, hiring is on the roadmap, or your team already knows it.

Vue:

• Easier to learn than React. Smaller community but growing.
• Less boilerplate, faster to get started.
• Hiring is slightly harder.
• Use if: you're a solopreneur or small team, speed matters, and complexity is low-to-moderate.

Svelte:

• The newest of the three. Smaller community still, but passionate.
• Build faster, bundle size smaller.
• Ecosystem is thin. You might roll your own for things you'd find a library for in React.
• Use if: you're contrarian, speed is critical, and hiring isn't on the roadmap.

Don't use: Angular, Ember, or anything else. They exist for reasons, but they're not the right choice for a new project.

For most projects, pick React. The community size alone is worth it.

How to choose your backend

The backend is where you handle authentication, data validation, business logic, and database queries.

Your choices:

Node.js (JavaScript):

• One language across frontend and backend. One team.
• Fast to get started. Loads of frameworks (Express, Fastify, NestJS).
• Performance is good for most workloads. Struggles under extreme CPU load.
• Use if: your team knows JavaScript, you want to move fast, or you're building an MVP.

Python (Django or Flask):

• Enormous ecosystem. Brilliant for data science and machine learning.
• Slower to run than Node.js or Go, but not noticeably for most apps.
• Community is huge. Documentation is mature.
• Use if: your team knows Python, you're doing data work, or you need maximum maturity.

Go:

• Fast. Compiled, not interpreted, so it's quick.
• Simple syntax. Goroutines make concurrency easy.
• Smaller community than Python or Node. Fewer libraries.
• Use if: performance is critical, you're building a data pipeline or API, or your team knows it.

Don't use: Java, C#, Rust (for most MVPs). They're for when you have specific constraints (extreme performance, extreme safety). They'll slow you down.

For most projects, use Node.js or Python. If you don't know either, pick Python: it's easier to read and learn.

How to choose your database

Your database stores your data. It's critical to get right because changing it later is painful.

PostgreSQL:

• Mature, battle-tested, free and open source.
• Powerful. Can do JSON, full-text search, arrays, ranges.
• Scales well. Many companies run on a single PostgreSQL for years.
• Use if: you're storing structured data, you have complex queries, you want boring reliability.

MongoDB:

• NoSQL document database. Data is JSON-like.
• Flexible schema. Easy to change the shape of your data.
• Slower queries for complex aggregations. Requires more thought about data structure.
• Use if: your data is unstructured or rapidly changing, or you need horizontal scaling early.

Firebase:

• Hosted database by Google. Realtime, no server to manage.
• Fast to get started. Built-in authentication, hosting, functions.
• Expensive at scale. Vendor lock-in. Less control.
• Use if: you're building a quick prototype, user authentication is heavy, or you want serverless.

Don't use: MySQL (Postgres is better), SQLite (only for tiny projects or offline apps).

For most projects, PostgreSQL is the right choice. It's boring, it works, and you won't regret it.

If Firebase appeals because "no server to manage," know that you're not avoiding complexity, you're outsourcing it. It's fine, but you trade cost for convenience.

How to choose your hosting

Where your backend runs. This matters more once you have traffic, but pick the right one at the start and you won't have to migrate.

Vercel:

• Purpose-built for Next.js. Easiest deploy. Git push and it's live.
• Good free tier. Costs grow with traffic.
• Best for frontend and serverless backend functions.
• Use if: you're building a Next.js app, you want zero DevOps, or speed is critical.

Railway:

• Simple, modern, good for startups.
• Docker-based, so you can deploy anything.
• Good pricing. Better support than Heroku.
• Use if: you want simplicity and good pricing, or your backend is Docker-friendly.

Render:

• Similar to Railway. Good free tier, simple dashboard.
• Great for web services and cron jobs.
• Use if: Railway is down, or you prefer their interface.

AWS:

• Most powerful. Cheapest at scale. Steepest learning curve.
• You configure everything. That's power and pain.
• Serverless (Lambda), containers (ECS), virtual machines (EC2).
• Use if: you have complex requirements, budget, and DevOps knowledge, or you're scaling hard.

Heroku:

• Simplicity and ease of use, but expensive. Getting worse over time.
• Use if: you inherited a Heroku app. Otherwise, pick something else.

For most projects starting out, use Vercel for the frontend and Railway or Render for the backend. Costs are predictable, they're easy to use, and you can upgrade to AWS later.

Questions to ask before you pick

1. What does my team know? This matters more than you think. Use what they know or can learn quickly.
2. Do I have specific constraints? Real-time data? Offline? Machine learning? Pick tools designed for those.
3. How fast do I need to ship? If speed is critical, pick boring. Shiny technologies cost time.
4. Will I need to scale? Most projects won't, not early on. Don't optimise for scale you don't have yet.
5. Is hiring on the roadmap? If yes, pick widely-used technologies. React, Python, Node, PostgreSQL.
6. Can I change my mind later? Mostly. Your frontend is easy to rewrite. Your database less so. Frontend flexibility should matter less than backend stability.

Tradeoffs to understand

Fast to ship vs hard to change: Boring stacks (React, Node, Postgres) are slightly slower to set up but very hard to regret. Shiny new stacks are exciting to write but painful to scale.

Managed vs self-managed: Firebase and Vercel manage everything for you, at a cost. AWS gives you control and lower cost but more to manage. Pick based on how much you care about operations.

Cost now vs cost later: Cheap now might be expensive later (MongoDB at scale is pricey). Expensive infrastructure now might save you weeks (Vercel vs self-hosting). Balance.

Single language vs polyglot: Building frontend and backend in one language (Node.js) is nice but not critical. Two languages (React and Python) is fine too. Don't let this decision paralyse you.