Choosing a tech stack comes down to your project, your team, and what you're optimizing for — not which framework is trending this quarter. That's the whole answer. Everything else is detail. I've shipped an AI real-estate app (Atikia), an e-commerce funnel platform (Lightfunnels), a construction-tracking app with real-time sync (AMG), and a high-traffic research video platform (JoVE), and every one of them used a slightly different stack for a specific, defensible reason. None of it was fashion.

This is the framework I actually use when a client hands me a blank repo and a deadline. It's four questions and four decisions. Answer the questions honestly and the technologies mostly pick themselves. The rest of this guide walks each decision in depth and links to a dedicated breakdown for each one.

The only 4 questions that actually pick a stack

Before you compare a single framework, answer these four. They do most of the work.

1. One language, or the best language per layer? If you're a small team or a solo freelancer optimizing for velocity, using JavaScript/TypeScript on both the frontend and backend removes an entire category of friction — no context-switching, shared types, shared validation, one mental model. That single decision quietly settles half of the others: pick JS/TS and your frontend is React, your backend is Node, and your ORM speaks TypeScript. The counter-case is a data- or AI-heavy product where Python's ecosystem is the actual value; then "best language per layer" wins and you accept the seam between a Python backend and a JS frontend.

2. How predictable and relational is your data? Predictable, relational, transaction-heavy data — users who place orders that contain line items that affect inventory — pushes you hard toward SQL. Data that's genuinely document-shaped, whose schema is still changing weekly, or that needs to scale horizontally across many nodes, opens the door to a document database. Most business software is the former. Be honest about which one you actually have.

3. How many clients touch the API, and how differently? One web frontend hitting your API? REST is almost always enough, and it's cheaper to run. Multiple clients — web plus native mobile plus partner integrations — each needing a different slice of the same data? That's when GraphQL starts paying back the complexity it costs you.

4. Are you optimizing for ship speed or long-term structure? An opinionated, batteries-included framework (Django, Rails, Angular) gets a solo dev to production faster because the decisions are already made. A flexible, assemble-your-own stack (Node with your picks, React) trades that head start for control that compounds as the app and team grow. Neither is "better." They're bets on different time horizons.

If you can answer those four, you've made the stack decision. The four sections below are just the detail on each column.

Frontend: React, Angular, or Vue?

For most people building products or freelancing, start with React. It has the biggest ecosystem — Next.js, React Native, and an enormous library market — the most job listings, and the gentlest on-ramp. Angular is heavier and more structured: routing, state, and HTTP are built in and enforced, which is genuinely what large enterprise teams want. Vue sits in between, ergonomic and approachable, with a smaller job market in most regions.

I build almost everything client-facing in React and Next.js, and the reason is leverage: the same mental model carries straight into React Native for mobile. The core skills that built this site (Next.js) also built the Atikia mobile app (React Native + Expo). One skill set, web and native. If you're weighing the specific tradeoffs and the 2026 job-market reality, I broke it down here: Should you learn React or Angular?

Backend: Node.js or Django (or something else)?

If your frontend is React/Next.js, Node.js is the natural fit — you keep one language across the entire stack, share types end to end, and avoid a second runtime to deploy and monitor. If you're Python-first or building something data/AI-heavy, Django hands you an admin panel, ORM, auth, migrations, and security defaults out of the box, plus a straight line into Python's ML ecosystem.

Node shines for real-time apps (chat, live dashboards, collaborative tools) and API-heavy workloads thanks to non-blocking I/O; Django shines for CRUD-heavy business apps you want in production this month. I run Node with Express or NestJS on most projects — it's what powers the backends behind Lightfunnels and the Lumin AI plugins — precisely because the frontend is React and one language keeps a small team fast. The full breakdown, with a situational decision table: Node.js or Django?

Database: SQL or NoSQL?

Default to SQL (PostgreSQL) unless your data model genuinely benefits from documents. Relational databases give you transactions, joins, foreign-key integrity, and strong consistency — exactly what you want the moment users, orders, and payments are involved. Reach for MongoDB when your data is authentically document-shaped (profiles, catalogs, content trees), your schema is still churning early on, or you need to scale writes horizontally.

In production I've used both, often side by side: Postgres for transactional data, a document store for flexible or event-shaped content. It's not a loyalty test. The full decision guide, with schema and query examples for each: SQL or MongoDB?

API style: REST or GraphQL?

Use REST by default. Use GraphQL when your clients justify the extra backend complexity. REST is simpler, caches naturally over HTTP and CDNs, and is trivial to debug with curl and Postman — which is why it still dominates production APIs. GraphQL earns its keep when you have multiple clients with different data needs, deeply nested UI data, or chronic over- and under-fetching pain.

The modern answer often isn't either/or: REST for public and CRUD endpoints, with GraphQL as a backend-for-frontend aggregation layer where the UI genuinely needs it. Here's exactly how I decide: REST or GraphQL? And if your React app is drowning in fetch/loading/caching boilerplate, the fix is usually a data-fetching layer like React Query, not a new API paradigm.

The stacks I reach for (and when)

Four defaults cover the overwhelming majority of what I build:

• Next.js + Node + PostgreSQL + Prisma — my default for web products. One language, server components, shared types from database to UI, and a great deploy story on Vercel. This portfolio runs on it. Reach for this when the data is relational and you want to move fast without painting yourself into a corner.

ts
1// Prisma gives you typed queries from schema to UI — no drift between DB and code
2const order = await prisma.order.findUnique({
3  where: { id },
4  include: { items: true, customer: true },
5});
6// `order.items` and `order.customer` are fully typed, all the way to the React component

• MERN (MongoDB, Express, React, Node) — when the data is authentically document-shaped and the team wants pure JavaScript end to end with a flexible early schema.
• React Native + Node — anything that has to be on iOS and Android from one codebase. This is Atikia (AI real-estate) and AMG (construction tracking, with real-time sync over WebSockets). The Node backend and the React Native frontend share language and types.
• React + Node + Stripe — e-commerce and funnels where payments, webhooks, and third-party integrations dominate the work. This is the shape of Lightfunnels and the Lumin AI plugins for Shopify, YouCan, and Lightfunnels.

Notice the constant: React on the front, Node on the back, one language across the stack. That's not dogma — it's the choice that keeps a solo freelancer or a small team fast. I break the default only when a specific requirement (heavy ML, an existing Python codebase, genuinely document-shaped data) pays for the seam it introduces.

A decision table you can copy

Find the row that matches your reality, then read the linked guide for each column to go deeper.

The four columns interact — your backend choice nudges your database, your client count nudges your API style — so don't decide them in isolation. Read the four decision guides linked above, and when you're ready to actually assemble the pieces into a working product, here's how to build a full-stack app end to end.