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 CodelitTry these templates
Project Management Platform
Jira/Linear-like tool with issues, sprints, boards, workflows, and real-time collaboration.
8 componentsSubstack Newsletter Platform
Newsletter publishing with subscriptions, paid tiers, email delivery, and audience growth tools.
10 componentsPrometheus Monitoring Stack
Metrics collection, alerting, and visualization with Prometheus, Grafana, Alertmanager, and exporters.
10 componentsContinue 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