The Stack I'd Use for Every New Project in 2026
I'm tired of "it depends"#
Every time someone asks "what stack should I use?" the answer is always "it depends." And while that's technically true, it's also useless.
So here's my actual stack. The one I use for every new project. No hedging.
The stack#
| Layer | Choice | Why |
|---|---|---|
| Frontend | Next.js 15 | App router, server components, deploys to Vercel in 30 seconds |
| Styling | Tailwind CSS v4 | I know people hate it. They're wrong. |
| Database | PostgreSQL (via Supabase) | It's always Postgres. Always. |
| Auth | Supabase Auth or Firebase Auth | Social logins, magic links, done. |
| Hosting | Vercel | Preview deploys, edge functions, zero config |
| AI | Claude API via OpenRouter | Best reasoning, OpenRouter gives model flexibility |
| Payments | Stripe | There's literally no other option worth considering |
| Resend | Beautiful API, great DX, actually delivers emails | |
| Monitoring | Sentry | Free tier is generous enough for most projects |
| Analytics | PostHog | Open source, self-hostable, doesn't sell your users' data |
Why this specific stack#
Next.js over everything#
I've used Remix, SvelteKit, Nuxt, plain React SPAs. They're all fine. But Next.js has the biggest ecosystem, the best deployment story (Vercel), and the most battle-tested patterns.
The app router took a while to get right, but in 2026 it's solid. Server components actually make sense now.
It's always Postgres#
MongoDB had its moment. But for 95% of apps, you want relational data with proper constraints and transactions. Postgres handles JSON too, so you get the flexibility of NoSQL when you need it.
Supabase gives you a managed Postgres with a great dashboard, real-time subscriptions, and auth built in. It's the fastest way from zero to production database.
Tailwind is not ugly#
"But it makes your HTML ugly!" Yeah, and CSS-in-JS makes your JavaScript ugly. At least with Tailwind I can look at a component and immediately know what it looks like without jumping to a separate file.
After v4, there's no real argument against it. The DX is just better.
What I don't use#
- Kubernetes — I'm not managing clusters. Vercel/Railway/Fly.io handle this.
- GraphQL — REST with good TypeScript types gets you 90% of the benefit with 10% of the complexity.
- Redux/Zustand for everything — Server components + React Query eliminated most client-side state management needs.
- Docker in development — I just... run things locally. It's fine.
See the architecture#
Here's what a typical project looks like with this stack:
Design your project architecture
Stop reading about architecture. Start building it. Describe any system and watch it come alive.
Launch CodelitContinue learning
Go deeper
As an Amazon Associate I earn from qualifying purchases. Codelit may receive a commission at no extra cost to you.
Building Microservices
Sam Newman · 2021
600 pages on splitting a monolith: service boundaries, data decomposition, migration order.
Designing Data-Intensive Applications
Martin Kleppmann, Chris Riccomini · 2026
Traces replication, consistency and consensus end to end, with the failure modes behind each choice.
3.6 (196)#1 in Data MiningSoftware Architecture: The Hard Parts
Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani · 2021
Works through service granularity, distributed data and saga patterns as full trade-off case studies.
4.6 (731)#2 in Software Design ToolsDatabase Internals
Alex Petrov · 2019
Explains B-trees, LSM trees and consensus protocols so you can predict how a datastore will behave.
4.6 (560)#2 in Management Information Systems