How It Started
As a backend developer, I used to treat every side project like a potential unicorn startup. I’d spin up a microservice architecture, integrate a message broker, add caching layers, and set up CI/CD pipelines — for a project that might never see a production user.
It wasn’t just excitement; it was a kind of technical vanity. I wanted my projects to be impressive under the hood. But after a few burnouts and abandoned repositories, I had to ask myself a hard question: Who exactly was I building all this for?
When Engineering Becomes the Obstacle
I realized the irony: my love for building elegant systems was actually preventing me from finishing anything. I’d spend weeks setting up infrastructure but never reach the feature that actually made the project valuable.
The truth: it’s not over-engineering if your system truly needs it — but 90% of side projects don’t.
Sometimes, I even caught myself designing systems for problems that didn’t exist yet, planning for scale I’d never reach. It was a security blanket — avoiding the messiness of product decisions by hiding behind technical complexity.
My Turning Point
One weekend, I decided to build a small internal tool to manage API keys. Instead of orchestrating containers and deploying to Kubernetes, I built a single Flask app, stored data in SQLite, and deployed to a $5 VPS.
It worked. It was fast. And, most importantly, it was done.
That weekend changed the way I approached side projects forever.
What I Learned
- Constraint breeds clarity: Limiting yourself (time, stack, scope) forces smarter decisions.
- Design for the first 10 users, not the next 10,000: Early validation matters more than architecture purity.
- Technical excellence follows product traction: Once something works, then scale it.
- Shipping small is a skill: It’s harder than it looks, but it’s the only way to learn quickly.
Today’s Rule of Thumb
Now, when I start something new, I ask myself:
- Can I build this in one file?
- Can I explain the architecture on a napkin?
- Would I still use this if it never scales?
If the answer to any of those is no, I’m probably over-engineering again.
Final Thought
Elegance in code isn’t about complexity — it’s about restraint. The best systems I’ve built lately are simple, focused, and, frankly, a little boring. But they work, they’re shipped, and they teach me something new every time. That’s all I want from a side project now.