If the goal is build products consistently for the next 3–5 years, I'd optimize for boring, well-supported technology rather than whatever is trending on social media.
My default stack in mid-2026 would look like this:
| Layer | Choice | Why |
|---|
| Language | TypeScript | One language across frontend, backend, tooling |
| Frontend | React + Next.js | Huge ecosystem, stable, hiring-friendly |
| UI | Tailwind CSS + shadcn/ui | Fast development without locking into a component vendor |
| Database | PostgreSQL | The safest long-term bet |
| ORM | Prisma or Drizzle | Both mature; Drizzle if you prefer SQL, Prisma for developer experience |
| Auth | Better Auth or Auth.js | Mature authentication without reinventing it |
| Backend | Next.js Route Handlers (or Hono if API-first) | Simple deployment |
| Validation | Zod | De facto standard |
| Forms | React Hook Form | Battle-tested |
| State | TanStack Query + React state | Avoid global state unless necessary |
| File Storage | Cloudflare R2 or S3 | Cheap and portable |
| Payments | Stripe | Still the easiest for SaaS |
| Email | Resend | Excellent developer experience |
| Analytics | PostHog | Product analytics + feature flags |
| Error tracking | Sentry | Worth the setup |
| Hosting | Vercel (frontend) or Cloudflare | Easy deployments |
| Background jobs | Trigger.dev or Inngest | Durable workflows without managing queues |
If I were starting from scratch today
I'd use something like:
- Next.js
- TypeScript
- Tailwind
- shadcn/ui
- PostgreSQL
- Drizzle
- Better Auth
- Stripe
- Resend
- PostHog
- Sentry
- Vercel
That's enough to build:
- SaaS
- AI apps
- marketplaces
- dashboards
- internal tools
- consumer apps
without needing major architectural changes.
Things I'd avoid
Heavy global state libraries
Most apps don't need Redux, MobX, or Zustand everywhere.
React state + TanStack Query covers a surprising amount.
Microservices
For one developer:
- one repo
- one database
- one deployment
wins almost every time.
Split later if there's a real reason.
Kubernetes
Until you're serving millions of requests or have a platform team, it's usually operational overhead rather than leverage.
Exotic databases
Unless your product specifically needs them, I'd avoid building around niche databases.
Postgres has earned its reputation by handling an enormous range of workloads well.
Premature event-driven architecture
Queues are useful.
Designing everything around events from day one usually isn't.
AI tooling
This has changed a lot.
I'd treat AI as a coding multiplier rather than my source of truth.
A setup I'd be happy with:
- An AI coding assistant in the editor
- ChatGPT for architecture discussions, debugging, code reviews, and writing
- Good test coverage so AI-generated code can be verified automatically
The important thing isn't which model is best this month—it's having a workflow where you can swap models without changing your project.
The biggest lesson from the last few years
Most churn happens in the AI layer, not the application layer.
React, TypeScript, Postgres, Tailwind, and Stripe have remained solid choices through multiple AI hype cycles.
If you keep your core stack stable and isolate AI integrations behind your own interfaces, replacing one model or provider is usually a small change rather than a rewrite.
If I only had one stack for the next five years
- TypeScript
- Next.js
- React
- Tailwind
- shadcn/ui
- PostgreSQL
- Drizzle
- Better Auth
- Stripe
- Resend
- PostHog
- Sentry
- Vercel
It's not the newest or most experimental stack, but it's cohesive, well-supported, and lets a solo developer spend more time shipping features than maintaining infrastructure.
