I’ve killed more side projects with architecture than with lack of motivation. Kubernetes for a todo app. Microservices for a blog. Event sourcing for a recipe tracker. If this sounds familiar, this post is for you.
I’ve watched hundreds of developers spend months setting up the perfect architecture for a side project that never launches. Don’t be that person.
The pattern
- Get an idea for a project
- Spend 2 weeks choosing the tech stack
- Set up a monorepo with Turborepo
- Add Docker, Kubernetes configs
- Set up CI/CD with 4 environments
- Configure monitoring and alerting
- Design a microservices architecture
- Lose motivation
- Never ship
Sound familiar?
What your side project actually needs
Day 1:
- One framework (Next.js, Astro, whatever you know)
- One database (SQLite or PostgreSQL)
- Deploy to one platform (Vercel, Railway, Fly.io)
That’s it. Ship it. Get users. Then add complexity when you have a reason to.
The premature optimization hall of shame
“I need Redis for caching” — You have 0 users. Your database handles 10,000 queries/second. You don’t need caching.
“I need a message queue” — For what? Processing 3 background jobs a day? Use a cron job.
“I need to containerize everything” — Your app is a Next.js site. vercel deploy and you’re done.
“I need a design system first” — Use shadcn/ui or Tailwind and ship. You can make it pretty later.
“I need 100% test coverage” — You need 0% test coverage and a shipped product. Add tests for the parts that break.
The stack for shipping
Framework: Next.js (or whatever you know best)
Database: SQLite (yes, really) or Supabase
Auth: NextAuth or Lucia
Styling: Tailwind
Hosting: Vercel (free tier)Total cost: $0 Time to deploy: 10 minutes Time to first user: today
”But it won’t scale!”
Correct. It won’t scale to 10 million users. It will scale to 10,000 users, which is 10,000 more than you have right now.
SQLite handles 100,000+ reads per second. Your side project will not hit that limit. If it does, congratulations — you have a real scaling problem, which means you have a successful product, which means you can afford to re-architect.
The only architecture rule for side projects
Solve problems you actually have, not problems you might have.
Every hour spent on infrastructure for hypothetical scale is an hour not spent on the feature that gets your first user.
What successful side projects have in common
They shipped fast with boring technology:
- Craigslist is still running on what looks like 1999 HTML
- Hacker News is a single-threaded Arc application
- Many profitable SaaS products run on a single server with PostgreSQL
Your side project doesn’t need to be architecturally impressive. It needs to exist.
The weekend test
Before adding any tool, library, or pattern to your side project, ask: “Would I set this up if I only had one weekend to ship?”
If the answer is no, skip it. You can always add it later when you have users who need it. The graveyard of side projects isn’t full of apps that used the wrong database — it’s full of apps that never launched because the developer was still configuring Kubernetes for an app with zero users.
Related: You Dont Need Microservices