The night I decided to stop building solely for other people
I write production code for a living. Distributed systems, microservices, the kind of stuff that handles real scale. I’ve optimized queries that saved lakhs in infrastructure costs. I’ve built things I’m genuinely proud of — architecturally.
But every one of those systems was someone else’s idea, someone else’s product. I decided what how looked like. Never what.
That’s a comfortable place to be. And comfort is exactly the problem.
The comfortable trap
Section titled “The comfortable trap”Here’s the thing about being an SDE in India that people don’t say out loud.
The money is good enough that you feel guilty wanting more. Your parents stopped worrying. Your LinkedIn looks impressive. Recruiters keep showing up with offers that are 20% more for the same work somewhere else.
From the outside, everything is fine. From the inside, you’re becoming a very skilled pair of hands. Someone writes a spec. You turn it into code. You do it well. You get a hike. Next spec.
I knew I could build. I’d proven it every day at work. What I hadn’t proven was whether I could decide what to build — and actually ship it.
The experiments
Section titled “The experiments”I’ve shipped 7 side projects over the years. A habit tracker. A markdown editor. A developer dashboard. None of them reached a user.
Same pattern every time: perfect setup on day one, a refactor on day seven, silence by day thirty. I kept treating side projects like production systems — architecting them for scale they’d never see, polishing code nobody would read.
I was optimizing for the wrong thing. I was optimizing for quality when I should have been optimizing for learning.
Each of those 7 projects taught me something — about what I actually enjoy building, about where I over-engineer, about the gap between “works locally” and “deployed.” They weren’t failures. They were expensive lessons in what not to do next time.
The moment that changed things
Section titled “The moment that changed things”Last month, I was using Claude Code for a work task. Nothing unusual. But I had an itch — instead of asking it to write a function, I described a full system. Frontend, backend, database, the whole thing.
Three hours later I had a working prototype.
Three hours. Something that would’ve taken me weeks manually. Not because I’m slow — because setup is slow. Config files, boilerplate, dependencies. The stuff that has nothing to do with the idea but takes 70% of the time.
That bottleneck — the one that killed every side project — just disappeared. Right there. In real time.
AI tools didn’t just make me faster. They removed the last barrier between knowing how to build and actually shipping.
What I’m doing now
Section titled “What I’m doing now”I’m learning by building. Each day, every day. Does it solve a problem? Ship it. Write about it. Next.
Gabru (ਗੱਭਰੂ) is Punjabi for someone bold, maybe reckless. The kind who jumps first and figures it out on the way down.
I’ve been careful for too long. Careful architecture. Careful abstractions. Careful taught me a lot, but it never put a product in front of a user.
Time to be a gabru.
If you’re an engineer who knows they can build but hasn’t shipped — the gap has never been smaller. The tools are too good now to keep making excuses. The bottleneck isn’t skill. It’s the decision to start and the drive to finish.
I made that decision. Now I’m building.
Follow the journey: @gabrubuilds on X for the daily, unfiltered version.
Frequently asked questions
Section titled “Frequently asked questions”Why build in public instead of privately?
Section titled “Why build in public instead of privately?”Accountability. Building in public means I can’t quietly close the repo and move on. It creates a forcing function — if I said I’m shipping, someone will notice when I don’t. And if even one other engineer sees this and thinks “I can do this too,” that’s the whole point.
How do you build daily with a full-time job?
Section titled “How do you build daily with a full-time job?”AI coding tools like Claude Code collapse the setup phase from days to hours. The bottleneck for side projects was never coding ability — it was boilerplate, config, and infrastructure. With those compressed, even a focused evening session can produce something real. Not every day produces something great. But every day produces something.
What does “gabru” mean?
Section titled “What does “gabru” mean?”Gabru (ਗੱਭਰੂ) is a Punjabi word for someone young, bold, and a bit reckless — the kind of person who jumps first and figures it out on the way down. It’s the opposite of my engineering instinct to plan everything before writing a single line of code.