--- slug: how-to-choose-a-tech-stack title: "How to Choose a Tech Stack for Your App Without Overthinking It" excerpt: "How to choose a tech stack without spending three weeks on Reddit. The decisions that matter, the ones that don't, and a 5-minute framework." primaryKeyword: "how to choose a tech stack" publishedAt: 2026-05-02 readingTimeMin: 8 author: "Robert Boylan" tags: - tech-stack - app-planning - indie-dev - vibe-coding - tool-comparison --- You have an app idea on Saturday morning. By Saturday afternoon you're nine browser tabs deep into "Next.js vs Remix vs SvelteKit 2026", a Hacker News thread is calling Postgres "boring," someone on Reddit is insisting you'd be insane to pick anything but Supabase, and another someone is insisting you'd be insane not to roll your own. You haven't written a line of code. You haven't even decided what the app does. That's the tech stack trap. It eats more weekends than any actual coding does. This post is about how to choose a tech stack for an app or website without disappearing into the comparison rabbit hole. Most of the decisions you're agonizing over don't matter for v1. The ones that do are simpler than the internet wants them to be. ## Why "what's the best stack" is the wrong question There is no best stack. There is only the stack that fits what you're building, what you already know, and how much code you actually want to touch. Those three constraints knock out most of the candidates before the comparison even starts. A tech stack, for anyone reading along who hasn't heard the phrase, is just the set of tools your app is built with. Frontend (what users see), backend (what runs on the server), database (where data lives), and hosting (where it all runs). Think of it like the kitchen equipment a recipe assumes you have. The same dish can be cooked on a gas hob or an induction one. The choice matters less than people pretend. When someone asks "what's the best stack for a SaaS app?", they're asking the wrong question. The right question is: "given this specific app, what's the smallest, most boring stack that gets it shipped?" That question has actual answers. The boring answer is also the answer that your AI coding tool will be best at. More on that further down. ## Start from what you're building, not what's trendy Before any stack decision, write down two things: what the app does in one sentence, and how the user will reach it. Phone? Browser? Both? You can't pick a stack without knowing this, and most people skip it because it feels too obvious to write down. A handful of common shapes and the obvious stack answers for each: - **A web app users open in a browser** (most indie SaaS, dashboards, planners, marketplaces): a single-page web app on something React-based, plus a small backend. Don't overthink it. - **A simple marketing site or landing page**: a static site framework. Astro, plain Next.js, or even a no-code tool. You don't need a backend yet. - **A mobile app users install from the App Store**: React Native or Expo if you want one codebase for iOS and Android, native Swift/Kotlin if you have a real reason. For a v1, almost always Expo. - **A side tool for one specific platform** (a Slack bot, a Chrome extension, a Discord plugin): the platform usually picks the stack for you. Read their docs first. - **A site that's mostly content** (a blog, a docs site, a portfolio): a static site generator. Astro or 11ty. Anything with a database is overkill. If your idea fits two of these shapes, pick one for v1. A "web app with a marketing site" is two products. Build the web app first; the marketing site is a single page until you have users. This step isn't glamorous. It's also the step that decides 80% of the rest of your stack, before you've read a single comparison post. ## The four decisions that actually matter Inside any stack, four choices do most of the work. The rest is detail you can change later without much pain. **Frontend framework.** For a web app in 2026, default to React (via Next.js if you want server-rendered pages, or plain Vite + React for a single-page app). Why React? Not because it's the best language design, but because every AI coding tool in existence has seen ten times more React code than anything else. Cursor, Claude Code, Lovable, v0, Bolt.new: they all generate cleaner React than they do Svelte or Solid. If you're going to lean on AI to write the code, lean toward what the AI has read the most of. If you're building a marketing site or a content-heavy site, swap to Astro. It's faster, simpler, and ships less JavaScript. **Database.** Postgres. That's it. Unless you have a specific reason that points elsewhere (a graph problem, time-series data at scale, a product spec that literally requires a different shape), the answer is Postgres. Hosted Postgres through Supabase or Neon means you don't have to think about it for the first thousand users. The "but Mongo is more flexible" debate ended a decade ago. Postgres has JSON columns now. You don't need a different database to store flexible data. **Backend.** This one depends on what you're building. For most apps that need user accounts and a database, the simplest answer is to skip writing a real backend and use Supabase or Firebase. They give you auth, a database, file storage, and a way to run small functions, all wired together. For a v1, that's enough. If your app needs heavy custom logic on the server, add a thin API layer in whatever language you're comfortable with. Node, Python, Go, Ruby. None of these will be the reason your app fails. If you're using Lovable, v0, or Bolt.new, the backend gets picked for you (usually Supabase). That's fine. Don't fight the default. **Hosting.** Vercel, Netlify, Cloudflare Pages, or Fly.io. Pick whichever your framework's docs use as the default example. You can move later. Hosting is the easiest decision to reverse and people spend the most time on it. Notice what's not on the list: monorepo tooling, state management libraries, CSS frameworks, ORMs, testing libraries. Those are choices you'll make as you go, and changing your mind costs an afternoon, not a rebuild. ## The case for a boring stack There's a kind of indie developer who picks the stack first and the app second. They want to learn Rust, so they're building "something with Rust." They want to try Bun, so they're using Bun. The app is a vehicle for the tech, not the other way around. That's a fine hobby. It's a bad way to ship. If your goal is to put something in front of real users, every interesting tech choice you make is a tax on shipping. Each unfamiliar tool means hours spent debugging something that has nothing to do with the product. Each cutting-edge library means you're the one filing the GitHub issues. Each "I'll just learn it as I go" item is a future stall. A boring stack means: technologies you already know, or technologies so widely used that every AI coding tool can write them in its sleep. A React + Supabase + Vercel app is boring. It's also the stack behind a thousand shipped indie apps in the last three years, and the stack your AI tool is most likely to get right on the first try. The corollary: if you're learning to code, picking a boring stack is a feature, not a bug. The community is bigger, the StackOverflow answers are still there, the documentation is mature, and your AI tool has more training data on it. Shiny new languages have none of those advantages, and the gap shows up exactly when you're stuck at midnight. ## Let your AI coding tool's strengths pick for you This is the part most stack-comparison posts skip, because a year ago it didn't matter. It does now. Your AI coding tool, whatever it is, has a stack it's strongest at. That's not a marketing claim from the tool's website, that's an observable thing. Cursor and Claude Code generate cleaner code in TypeScript than in Swift. Lovable and Bolt.new are explicitly built around React + Supabase. v0 is built around Next.js + shadcn/ui. Figma Make outputs React. Even Copilot has measurably better completions for JavaScript and Python than for, say, Elixir. If you're going to spend the next month asking an AI to write 70% of the code, ask the AI what it's good at and pick that. The cost of fighting your tool's defaults shows up everywhere: more retries, more wrong-shaped code, more "wait, that's not how this works" moments. A simple test: open your tool of choice and ask it to scaffold a "to-do app with login." Look at what it picks. That's the stack the tool will be most fluent in. Unless you have a strong reason to override that default, don't. This is the same reason [a clear spec gets better code from your AI tool](/blog/why-ai-keeps-rebuilding-features) than a vague one: meeting the tool where it's strong is half the battle. ## A 5-minute framework you can run right now Stop reading comparisons. Run this: 1. Write your app idea in one sentence: "My app lets [person] [do one thing]." 2. Pick a shape: web app, mobile app, content site, marketing site, platform plugin. 3. Decide if you're touching code or not. If you're not, pick Lovable, v0, or Bolt.new and stop here. The stack is whatever they default to. 4. If you are touching code, default to: React (Next.js for full-stack, Vite for SPA), Postgres via Supabase, Vercel for hosting. Override only if you have a real reason ("I already know Django" is a real reason; "Next.js is mainstream and I want to feel different" isn't). 5. Set a 24-hour rule: you can't change a stack decision in the first day. If after a day you're genuinely blocked by a choice, change it. If you're "just exploring alternatives," you're procrastinating. That's the whole thing. Five minutes, four decisions, one default, one escape hatch. The reason this feels too simple is that the internet has spent a decade making stack choice into a personality test. It isn't. It's a logistics decision. Pick the boring option, ship the v1, and revisit the stack when you have users complaining about something the stack actually caused. Most apps never get there. ## What to do before you commit Before you open the IDE, the no-code builder, or the chat box, write down four lines: - What the app does, one sentence. - The shape (web, mobile, content site, plugin). - Your stack: frontend, backend, database, hosting. - One thing you're choosing not to use that you were tempted by, and why. That last line is the cheat code. Naming the thing you're not picking, and why, settles your brain in a way that just picking can't. It also gives you a paper trail if you do hit a wall later and need to revisit. Picking a stack is the easiest part of building an app to overthink, because every decision feels load-bearing in the moment. Most aren't. The thinking that actually matters lives upstream: what are you building, who is it for, and what's the smallest version that proves it works. If you've nailed those, almost any reasonable stack will get you there. That upstream thinking is what [Draftlytic is built around](/). You describe the idea, answer a few focused questions, and walk out with a spec that already implies the right shape, the right scope, and a stack that fits. The stack debate doesn't go away. It just stops being the place you get stuck.