14+ shipped projects in 3 years. Not as hobbies — as a practice.
When people see my projects page, the first question is usually some version of: “How do you find the time?” The second, more interesting question is: “Why?”
I’m an Engineering Manager. My day job is leading a team of 12, making architectural decisions, running retros, unblocking people. I don’t need to build side projects to prove I can code. So why do I keep shipping things on evenings and weekends?
I can read about semantic search, or I can build Biz Browsing — semantic search over 4.8 million company records — and learn what actually happens when you embed that much data, how retrieval breaks down at scale, and what the cost curve looks like.
I can read about LLM agents, or I can build IdeaMaze — a framework that runs 155 autonomous AI experiments — and discover that agents will game their own metrics if you don’t build honesty checks.
Reading gives you knowledge. Building gives you intuition. When my team at DriveX proposes an architecture for a new AI feature, my intuition about what will work and what won’t comes from having built similar things myself. Not at their scale, not in their context — but enough to ask the right questions.
The hardest part of moving from IC to manager is the gradual erosion of technical depth. You spend your days in meetings, Slack, and docs. Your coding skills atrophy. After a year, you’re reviewing code you couldn’t write yourself.
Side projects are my hedge against this. Every project forces me to deal with the full stack — from choosing a framework to deploying to production. I’m not delegating any of it. I’m writing the Dockerfile, debugging the CORS issue, optimizing the database query.
This has a direct payoff at work. I can review pull requests with real understanding, not just pattern matching. I can estimate timelines accurately because I recently felt the friction of building something similar. I can call out when something is over-engineered because I know what the simpler version looks like.
A side project has a natural arc: idea → prototype → ship → learn → move on. The whole cycle might take a weekend or a few weeks. Compare this to work projects that span months, where the feedback loop between “decision” and “consequence” is so long you can barely connect them.
Side projects give you dozens of compressed decision-consequence cycles per year. Each one sharpens your judgment a little. Over 14+ projects, the cumulative effect is significant.
Here’s what some of them taught me:
Every shipped project is a proof of work that compounds over time. When I interview for a role, I don’t just have a resume — I have a portfolio of things I built, deployed, and can talk about in depth.
More importantly, each project is a potential conversation starter. IdeaMaze led to conversations about AI research methodology. The WhatsApp auction platform opened doors in the conversational AI space. You can’t predict which project will matter, so you build a lot and let serendipity work.
I don’t have a secret productivity system. Here’s what’s true:
The real reason I build side projects is simpler than all of this: I’m an engineer who likes building things. Moving into management didn’t change that. It just changed what I build during the day.
The side projects are the part of my work where I’m still the person writing the code, making the decisions, and seeing the immediate result. That direct feedback loop — I built this, it works, someone used it — is what got me into engineering in the first place.
I don’t plan to stop.
See all my projects at rohitagarwal.dev/projects.