Tech Stack Picker

Why the stack decision matters more than the code

The single biggest lever on how well Claude Code builds your project is the stack you point it at. Give it React, Postgres, and a common Node server and it writes fluent, idiomatic code because those tools appear in millions of examples. Point it at something obscure and it has less to draw on, so you spend more time correcting and less time shipping. This picker asks five honest questions and returns a stack chosen to be both a strong technical fit and something Claude Code handles well.

There is no single best stack, only a best stack for a given set of constraints. A solo builder who wants to ship this weekend should not adopt the same architecture as a six-person team building for scale. The recommendation adapts to your app type, your top priority, your team size, your experience, and whether you need realtime - and it tells you why each layer was chosen, so you can agree or override with your eyes open.

The four layers, and what actually drives each one

• Frontend - driven mostly by app type. A content site wants Astro for speed and SEO; a rich web app wants React (via Vite when simple, Next.js when it needs to scale); mobile wants Expo for one codebase across platforms.
• Backend - driven by priority and experience. Beginners and speed-seekers do best with a backend-as-a-service like Supabase so they never run a server; scale and larger teams justify a dedicated TypeScript API.
• Database - Postgres is the right default for almost everything. The only real forks are 'no database needed', 'add Redis for realtime', and 'managed versus self-run'.
• Hosting - driven by app type and scale. Vercel is the fastest path to a live URL for most web work; container hosts win when you need long-running servers; CLIs and mobile apps are distributed rather than hosted.

Speed, scale, or simplicity - pick your bias honestly

The priority you choose reshapes the whole recommendation, so choose the one that is actually true, not the one that sounds impressive. If you have never shipped this kind of app before, 'scale' is almost always the wrong answer - you will pay setup cost for headroom you will not use for months. Optimizing for speed or simplicity first, then migrating a single layer later when you have real traffic, beats over-engineering on day one nearly every time.

Why these picks are Claude-Code-friendly specifically

Every default here was chosen partly for how well an AI coding agent works with it. TypeScript everywhere gives Claude Code types to reason against and catch its own mistakes. React, Postgres, and Express are the most heavily represented tools in training data, so generated code needs less correction. Managed services like Supabase and Vercel remove whole categories of infra work that are error-prone to script. The result is a stack where the model spends its effort on your features instead of fighting unfamiliar tooling.

How to use the recommendation

1. Answer the five questions honestly - especially priority and experience, which move the result the most.
2. Read the reasoning under each layer, not just the label. The 'why' is where you decide whether to agree.
3. Copy the full stack and reasoning and paste it into Claude Code as the opening context for your build.
4. Override any single pick your real constraints demand - existing code, team skills, or compliance always win.
5. Start building the frontend and database first; wire the backend and hosting once you have something to serve.

When to ignore this tool entirely

If you already have a codebase, keep its stack - consistency beats theoretical optimality every time, and rewriting a working app to match a recommendation is almost never worth it. If your team has deep expertise in a specific tool, that expertise usually outweighs a marginally better default. And if you are learning on purpose, pick the stack you most want to learn, not the fastest one. This picker is a strong starting point for greenfield projects, not a mandate.