1
1 Comment

The Tech Stack Behind My Side Projects (And Why I Stick to It)

Over the years, I’ve built multiple side projects—some flopped, some gained traction, and one even got acquired (LectureKit, which I sold for $6,750). Throughout all of them, I’ve stuck to a tech stack that’s simple, scalable, and most importantly—fast to set up.

I’m a big believer in not reinventing the wheel. The more I reuse tools I already know, the less time I spend debugging infrastructure and more time I spend actually building. Even if something isn’t the absolute cheapest option, you shouldn’t undervalue your time.

Here’s what I use for all my projects:
Hosting & Infrastructure
AWS Lambda & EventBridge – For serverless functions, web scraping & event scheduling (less maintenance, scales automatically).

AWS S3 & CloudFront – For storing assets and serving them via a CDN.

Railway – I host my Node.js backend & APIs here because it’s easy to set up, doesn’t cost much, and saves time compared to configuring my own servers.

Database & Storage
MongoDB Atlas – Free tier is great for getting started, managed hosting saves me time.

AWS S3 – Used for storing images, scraped data, and backups.

Frontend & Full-Stack Apps
Next.js & Vercel – Quick to deploy and great for full-stack apps. If a project starts generating revenue, I switch to AWS Amplify for more control.

Backend & APIs
Node.js with Fastify – Faster and lighter than Express, making it my go-to for APIs.

This is exactly the setup I used for https://CaptureKit.dev, my latest project.

AWS Lambda powers the web scraper.

Fastify runs the API efficiently, hosted on Railway.

Next.js is used for the dashboard and project collaboration features.

This stack lets me ship fast, scale when needed, and minimize costs early on. I don’t spend time optimizing things that don’t need optimization yet.

If you’re building a side project, don’t overcomplicate things. Pick tools you already know and focus on getting the product in front of users.

What’s your go-to tech stack for side projects?

on March 9, 2025
  1. 1

    Your stack seems solid. I like this pragmatic approach. That “ship fast first, optimise later” mindset is usually what separates projects that actually launch from ones that stay in setup mode forever. One thing I’d add from my own experience: early-stage stacks don’t really fail on tech, they fail on friction. The more services you stitch together (Lambda + Railway + MongoDB + S3 + CDN), the more moving parts you end up babysitting as things grow.

    For side projects where speed matters even more than fine-grained control, I have had good results using Backend-as-a-Service options like Back4app.com. You get auth, database, file storage, and APIs in one place, which removes much of the early glue work and lets you validate ideas faster.

    Similarly, if you are already comfortable with AWS, your setup makes sense. Otherwise, tools like Supabase or Firebase are great for fast MVPs since they bundle auth, database, and storage, while Railway or Fly.io keep backend deployment simple without heavy ops.

Trending on Indie Hackers
I shipped a productivity SaaS in 30 days as a solo dev — here's what AI actually changed (and what it didn't) User Avatar 300 comments I built a tool that shows what a contract could cost you before signing User Avatar 109 comments The coordination tax: six years watching a one-day feature take four months User Avatar 72 comments My users are making my product better without knowing it. Here's how I designed that. User Avatar 59 comments I changed AIagent2 from dashboard-first to chat-first. Does this feel clearer? User Avatar 28 comments Stop Treating Prompts Like Throwaway Text User Avatar 14 comments