My Overengineered Side-Project Stack

I build a lot of side projects. Most of them never see another human being. A few fortunate ones make it to production. But regardless of how many people use them, I love the process — late nights, quick prototypes, and shipping something just because it sounds fun and gives instant gratification.

Here are a few recent ones:

• Ask Them Out — AI-powered, gamified e-invitations (ask-them-out.com)
• Scattegories Arena — Multiplayer Scattegories online (scattegories.ishaan812.com)
• Mnemo — A WhatsApp-based AI assistant for busy executives (mnemo.ishaan812.com)
• Rift Wrapped — Spotify Wrapped for League of Legends, a hackathon project (riftwrapped.ishaan812.com)

…and many more that never made it out of my local machine.

Over the past months, I've been rebuilding how I host and deploy all these experiments. Until recently, I'd rely entirely on free tiers at Vercel, Fly.io, or Railway — and honestly, that's still definitely the smartest path when you're starting out.

But I ended up receiving a bunch of AWS credits after a hackathon win and decided to use that as an excuse to finally build a deployment stack that fit how I work.

This post is about why I overhauled everything, what was breaking in the old model, and what my new stack looks like today.

Why I Decided to Change My Entire Workflow

I build things fast. I also abandon things fast.

A typical side-project failure for me looks like this:

• Project hits free tier limits
• Some API key expires
• Random API starts failing suddenly
• Long-running tasks break
• I get bored and move on

That cycle was annoying. And because I jump between ideas frequently, the friction of fixing deployment issues usually killed the project quicker than anything else. My goal became simple:

Increase my velocity and decrease friction, so I could build things faster — and most importantly before I get bored of them and move on to something else.

To do that, I needed something more flexible than Vercel, but not as painful as manually setting up EC2 for every project.

What Was Breaking in My Old Setup

1. Vercel + Next.js API Limitations — I've always loved working with Next.js because the developer experience is incredibly smooth, but the serverless API layer repeatedly slowed me down in real projects. Handling large file uploads was unpredictable, long-running backend tasks would often die because of Lambda timeouts, and cold starts became annoying at exactly the wrong moments. Anything that leaned more "backend-heavy" — like long AI inference calls, scheduled jobs, or tasks that needed a lot of memory — felt unnatural in the serverless model. These limitations make complete sense once you understand how serverless architecture works, but for my style of fast-paced experimenting, they were nuisances that kept getting in my way. It was also annoying how this all seemed to work on local but started failing once I deployed to Vercel.

2. Fly.io & Railway Friction — Fly.io and Railway were the set of platforms I leaned on, especially when I needed to deploy multi-service projects with Docker. They were powerful, flexible, and in theory perfect for the kind of things I built. But in practice, the friction added up. Free tiers would run out at the worst times, scaling behavior on the cheaper plans was unpredictable, and debugging became painfully difficult when containers failed silently. Both platforms are genuinely excellent, but they weren't a good fit for my chaotic "spin up 10 side projects in a month and forget about 9 of them" workflow. I needed something more stable and more under my control.

The Self-Hosting Era

Eventually, I decided to try hosting everything myself on EC2, and it was surprisingly fun. Having my own virtual machine meant I suddenly had full control over everything — no black boxes, no missing logs, no platform quirks to guess around. I ended up learning far more about Nginx, Docker, networking, and Linux tuning than I expected, and the best part was that when something broke, I couldn't blame anyone else. That forced me to actually understand the system instead of yelling at a platform. It definitely required more effort upfront, but in exchange, there were far fewer surprises later.

Once I had EC2 servers running, I started using them for more than just deployments. I ran my own WireGuard VPN, used them for personal storage, experimented with heavier backend workloads, and deployed multi-container apps without caring about memory limits or execution time. It felt freeing, but it also came with a realization: spinning up a new EC2 instance for every single project is completely unsustainable. Managing multiple machines, maintaining different Docker setups, and constantly editing Nginx configs meant I was essentially DIY-ing my own PaaS by hand. What I needed was something in the middle — not as abstracted as Vercel, but not as bare-bones as manually maintaining five different VPS machines. I wanted control without the repetitive setup work.

My New Stack: EC2 + Dokploy

That's when I came across Dokploy, and it immediately felt like the middle ground I'd been searching for. It let me stay fully self-hosted on my own EC2 instances, keep everything running through Docker, and still enjoy a deployment experience that didn't feel like wrestling with infrastructure every time I wanted to ship something. Instead of manually editing Nginx configs or juggling separate Docker Compose files for each project, Dokploy gave me a clean layer on top: one-click deployments, automatic SSL, built-in logging, secret management, private registry support, and a surprisingly pleasant UI for managing everything in one place. It felt like Vercel but without giving up any of the control.

The best part was how dramatically it simplified my workflow. I could create a repository, write some code, push it, and Dokploy would handle the rest without me touching the server. Deployments became a background activity instead of a separate project on their own. For someone like me, who jumps between ideas constantly, this level of automation was perfect. It was just the right amount of overengineering: enough control to keep me happy, but enough abstraction to keep the chaos away. It also looks super pretty (image below of my setup).

Along with this, I also reorganised all my repos to all be subtrees in a monorepo since I tend to get them lost all the time and it's nice to have everything in one place, along with my server setup scripts and WireGuard setup — pretty much everything I would need to clone to set up this server quickly on any other VPS.

Why This Works Better for Me

Since switching to this stack:

• I spend more time building and less time fighting hosting quirks
• I deploy more often
• I abandon fewer projects due to annoying infra issues
• I can experiment with heavier backend logic that Vercel wouldn't like
• I don't fear adding more services like Redis or background workers or even small scripts for automating something
• Everything is in one dashboard, which helps me keep track of stuff before I forget it exists

It's not for everyone. For most beginners, Vercel + serverless is still the best option. But for someone like me who likes experimenting, self-hosting, and pushing weird multi-service projects, Dokploy + EC2 hits the perfect balance.

And yes, I know this stack is overkill for projects with 3 users.

But that's the point.