I’ve shipped a lot of side projects. Most got abandoned. A few turned into businesses. The stack you pick at the start matters more than people think, but probably not for the reasons you think.

Here’s what I’ve learned about stack selection, ordered by what actually matters.

Rule 1: Pick what you already know

Side projects die from boredom and friction, not from technical inadequacy. If you already know Next.js, use Next.js. If you know Rails, use Rails. The hour you spend learning a new framework is an hour you didn’t spend on your actual idea.

The only exception: you’re picking the project specifically to learn the stack. That’s fine. Just be honest about it.

Rule 2: Boring databases

Postgres. Use Postgres.

Yes, SQLite is fast. It’s also what I reach for when I need an embedded DB. For a side project that might grow into something, Postgres is free, runs everywhere, has every feature you’ll ever need, and won’t surprise you in two years.

Not MongoDB. Not “we’ll figure out persistence later”. Postgres, on day one.

Rule 3: One language for the whole stack, if possible

The tax of context-switching between TypeScript on the frontend and Python on the backend is real. It’s not crippling. But for a solo project, the cognitive overhead of remembering which language’s quirks apply right now adds up.

I default to TypeScript everywhere. Hono or Elysia for the API. SvelteKit or Next.js for the frontend. Drizzle or Prisma for the database. One mental model, one set of tools, one editor configuration.

If your strength is Python, do Python everywhere with FastAPI plus HTMX. If it’s Go, do Go everywhere. The stack matters less than the consistency.

Rule 4: Hosting that doesn’t charge you for sitting still

Free tiers used to mean “get rate-limited at 100 requests an hour.” Now they mean “host your side project for free until it’s actually a business.”

Cloudflare Pages, Vercel hobby, Netlify free, Fly.io’s free allowance, Supabase free tier, any of these will host a side project for years at zero cost. Pick the one whose interface doesn’t annoy you.

Don’t pay for a $40/month Heroku dyno on day one. You don’t have users yet. The day you do, migration is a weekend.

Rule 5: Authentication is solved

Don’t write your own. Don’t even use Passport.js. In 2026 the right answer is one of: Clerk, Auth.js, Supabase auth, Better Auth, or, if you’re allergic to dependencies, copy-paste a passwordless email link implementation from a tutorial.

Authentication is the place where AI-generated code will eat you alive. Use a library written by people whose full-time job is thinking about session security.

What to avoid

Microservices. You don’t need them. You won’t need them for the first 100,000 users.

Custom CSS frameworks. Tailwind has won. Open-props if you want a vanilla CSS escape hatch. Anything else is yak-shaving.

A Kubernetes cluster. If your side project starts on Kubernetes, it’s not a side project. It’s a hostage situation.

The newest framework. I love checking out every new release. I don’t put my side projects on them within their first year. Bugs that would take a senior engineer 4 hours to debug will take you a weekend, and you’ll resent the project.

The actual answer

For most people reading this in 2026: SvelteKit or Next.js, Postgres on Supabase, Tailwind, Auth.js, deploy on Vercel or Cloudflare Pages. That’s the boring answer. It’s correct.

The interesting choices come later, when your project has actual constraints.

Picking a stack for a side project (without regretting it in a year)