DEV Community: Saksham Kushwaha

Scratch your own itch: How to Build and Ship

Saksham Kushwaha — Mon, 06 Oct 2025 18:29:50 +0000

"Scratch your own itch."

It's a phrase I first encountered in the book Rework by Jason Fried and David Heinemeier Hansson (a great book, btw!!). The idea is simple: solve the problems that you personally encounter. The logic behind this is powerful. When you solve your own problem, you understand its ins and outs completely. You know the exact nuances, the frustrations, and what a perfect solution would feel like. This intimate knowledge ensures you'll build something that genuinely fixes the problem at its core.

Imagine the alternative: you ask someone else to solve a problem for you. Now, you have to rely on constant external feedback. Even with great communication, the final product might miss a subtle detail that only someone struggling with the problem would truly understand.

This brings me to why I'm writing this. A few days ago, I conducted a Git/GitHub workshop. We covered the basics, but time ran out before I could get to the bigger questions I'm often asked—questions about how to find ideas, contribute to projects, and actually get them out into the world.

So here we are. This blog post is my attempt to cover the things I actually wanted to discuss, all of which circle back to that one core idea: scratching your own itch.

Step 1: Start Small by Contributing to Open Source

This part might feel a bit detached at first, but it's the perfect starting point. The easiest way to get into building things is by improving things that already exist.

So, how do you start contributing? The answer is to find a good open source project in your preferred tech stack and start using it regularly. For example, if I wanted to get into Android development, I'd go to platforms like Peerlist, Product Hunt, or browse Twitter's #buildinpublic and Reddit's r/buildinpublic. These places are filled with open source projects you can explore.

Why does this matter, though? Because once you start using a product, you'll naturally notice bugs or think of features that could improve it. You can then raise these as issues on GitHub, get assigned to them, and solve the bug or add the feature you want. You're scratching a small itch within a larger project.

Plus, if you're a beginner, you can search for issues labeled "good first issue". These are typically straightforward and can help you learn the essential workflow of making pull requests (PRs) and collaborating on a real project.

Also don't just freaking DON'T follow those didi bhaiya channels 😭 ... their students now bombarded node.js repo after express.js when will they ever learn 😭😭.

Step 2: Find Your Big Idea by Scratching Your Own Itch

Now for the main event: coming up with your own project ideas.

The answer is right there in the title of this blog... it's always "Scratch your own itch." Solve something that you personally struggle with. Find a point of friction in your own workflow and eliminate it. Friction is the single biggest driver of creation.

Personally, I created Monochromate because no other browser extension had all the features I wanted in a greyscale tool. Since it was my problem, I knew every corner of it. Surprisingly, I found out others wanted the exact same thing. They started suggesting cool features, and this small community helped make Monochromate the best greyscale extension in the marketplace (yes, I can say this with full confidence :>).

Let's forget about me for a while. We all know how Linux and Git came into existence, right? There are always brilliant devs like Linus Torvalds who eventually say, "Fine, I'll do it myself." As programmers, we often start a project not because we know it's easy, but because we think it will be easy, haha. But that's how it works. That's how developers come up with great ideas or improve upon others' projects, adding their own flair to make them better.

Step 3: Don't Just Build, Ship It!

This part is crucial, and it's where most people stop. You've built something cool... now what?

Truth be told, I haven't mastered the art of promotion yet, but I've learned a few things that work. The most important one is this: show what you're building, as you're building it. Post about your progress on X, Reddit, or whatever social media you use. This creates hype and builds an audience before you even launch.

Don't let your projects just sit in a GitHub repository. Launch them. Put them on Peerlist and Product Hunt. Track where your users are coming from and double down on those sources. Write blog posts about your journey and share them on Dev.to, Medium, Substack, and your own site. Build your project for yourself, but share it for everyone else who might need the same solution.

Sometimes it will work, sometimes it won't. Monochromate took off after a Hacker News post resonated with the right audience, and it jumped from 100-ish users to over 300 in just a few days. On the other hand, I've promoted my latest product, LeetJump, on several platforms without getting much traction yet. This doesn't mean one product is better than the other; it just means I probably haven't found the right audience for it yet.

If you need a more structured plan, the 6-week cycle from buildspace is a fantastic template:

Week 1: Introduce Your Idea. Craft a one-liner and share it publicly.
Week 2: Build a Toy Version. Create a basic demo and show your progress.
Week 3: Launch and Get Interest. Make a launch video and aim for your first 10 users.
Week 4: Iterate and Relaunch. Improve your project based on feedback and launch again.
Week 5: Focus and Experiment. Pick the most common feedback to address, then launch on a completely new platform.
Week 6: Tell Your Full Story. Create a final "demo day" video showing your journey and what's next.

It's a Cycle

And that's really all you need to build and ship. Start small, find your own problem, build the solution, and share it with the world.

Speaking of which, I’ve started working on a new project following this same philosophy. I’ll be posting updates over on my social media handles soon you can follow me there for the updates. If you’re building something too, feel free to follow along! :)

building the CLI tool that I wish shadcn/ui had

Saksham Kushwaha — Thu, 26 Jun 2025 21:36:50 +0000

So I’ve been using shadcn/ui for about 1–2 years now, and honestly, while I love it, it comes with its fair share of friction, friction you only realize after you actually start using it regularly.

For me, the first major pain point was theming as editing CSS variables was a hassle because of how many there are. Thankfully, TweakCN came to the rescue (love this product). But the more I worked with shadcn, the more I realized that the friction was also present somewhere else and that was CLI.

The CLI has like three commands, and I usually only touch two of them: init and add. But they are so full of friction.

So last week, I decided to build my own open source CLI tool, something that would actually make using shadcn a smoother, more fun experience. The idea was to
make a shadnc/ui CLI wrapper that handles component setup in a much cleaner and intuitive way.

Oh and the name?
You’ve got components + addition + shadcn = COMPADCN.
Yeah, I know. 🔥

I knew nothing about cli tool developments when I started this project. Just some basic knowledge, and then watched some videos, read through codebase of t3-oss/create-t3-app and consulted GPT and Claude to finally figure out the tech stack and it turned out to be Typescript + @clack/prompts + commander.js + chalk

And then in a day or two I had the first command working

`compadcn add`

This one’s exactly what it sounds like. It lets you add components. But instead of typing like shadcn@latest add button card calendar every single time... you just launch a TUI component selection tool, pick what you want, and boom that's all you need it handles the rest. Under the hood, it’s still using the official CLI. But now, you don’t have to.

While chatting with a friend about this project, he casually mentioned that he just uses the --all flag to install every component up front, to avoid having to add components one by one.
Honestly? That sounded cursed at first.
But the more I thought about it, the more it made sense... because the friction is real.

That conversation inspired my second command:

`compadcn lint`

It scans your project and lists all the unused shadcn components you’ve installed.
After a few iterations, I added another prompt that lets you remove those unused components right then and there.

Now, I had two solid commands... but something still felt missing.
That’s when presets clicked into place.

`compadcn presets`

We all have that list of components we install every single time we start a new project. Even with the TUI from add, doing it again and again sucks. So why not make presets?

Presets are simply a list of components you can install with a single line.
By default, compadcn ships with 9 built-in presets, and you can make your own too. They're stored in ~/.compadcn/custom-presets.json.

Now you may a list of over 40+ components but the CLI for installing them will just be:

compadcn p i <preset_name>

Short, sweet, and done.

You also get 5 subcommands for listing, viewing, deleting, creating, and installing presets.
Bonus: if you already have a component installed, it won’t add it again. No bloat.

and then came my final command:

`compadcn remove`

This one’s all about cleanup. If you’re removing a component, you shouldn’t have to manually:

Delete the component file
Remove its import statements
Uninstall its dependencies

So compadcn remove does all of that for you.

When you run it, it lists all installed components. You can select the ones to remove, and it will handle everything plus, it prompts you if there are dependencies to uninstall too.

But I had to be careful with internal dependencies.
For example, if you try to remove the button component but still have calendar installed (which depends on it), the CLI won’t let you break things. It respects those internal links.

Same goes for mutual dependencies, it won’t show you the option to remove shared ones unless both dependents are selected.
It basically functions as an automated shadcn component removal tool.

That’s where compadcn stands for now, built in under a week, with zero prior CLI experience.
If you use shadcn in your projects and want to save time, reduce repetition, and stay in flow, I genuinely think it’ll make your workflow better and let you speedrun through several of tedious tasks

I’d love feedback, stars on GitHub, or even bug reports.
The CLI is open source:
https://github.com/lirena00/compadcn

also designed a cool landing page for it if you are up for it haha : https://compadcn.lirena.in/

PS: thanks for reading it so far, I launched this product at producthunt and peerlist but so far it's not doing that good so if you would like to support it a bit you can find the links on the landing page and yea that's it!! thank you once again.

How a Potato PC and Friends Made Me a Developer.

Saksham Kushwaha — Fri, 21 Mar 2025 18:32:53 +0000

So, the year was 2016. I was in 6th standard, learning the basics of HTML because it was part of the course.

One day in the computer lab, this classmate—who I kinda despised for some dumb kid reason—starts showing off an HTML page he made. It wasn’t anything wild, just a simple page, but it was way cooler than what we’d been taught.I wasn’t just curious—I was jealous. I had to beat him at his own game. So, I went home, Googled like crazy, and stumbled on W3Schools. There, I found the tag, I tested it on my dad’s laptop — and it seemed like sorcery!!

That petty rivalry lit a fire (Totally not anime style). We both kept pushing to outdo each other, and somewhere along the way, I forgot why I even disliked him. We ended up friends—actually, he’s one of my best buds now. He got me hooked on batch scripts (think Matrix-style effects), and by the end of 6th standard, I was pretty decent with CSS. We’d mess around making dummy homepages, and it was honestly a blast.

That spark of curiosity led me to Python next. I will be honest, I hated loops at first—they just didn’t click. Frustrated, I dropped Python and stuck to HTML and CSS for a bit. But a few months later, I gave it another shot, and suddenly, loops made sense. They were actually cool! That old rivalry also nudged me toward GUI stuff like Tkinter and PyQt5. I built small projects, like a beat player I called Beatox—basically a laggy drum pad for loops. It wasn’t perfect, but I was proud.

Fast forward to 9th standard: I was decent with Python and itching to build something big—partly to make my friend jealous again. Around then, I got into anime. My first was Sword Art Online (yea it’s not that good I get it but it was to the me back then), and it blew my mind—virtual reality games felt like the ultimate dream. Then COVID hit, and I was stuck at home, bored. Among Us blew up, my friends wanted to voice chat, and I joined Discord. A few months in, I found this RPG bot based on Demon Slayer and got obsessed grinding it. I even tinkered with Selenium to auto-farm a little. That’s when I discovered Discord.py and decided to make my own bot inspired by Black Clover, an anime I loved.

Building that bot was brutal. Big lesson learned: skip tutorials and read the docs. Long story short I spent two weeks on a basic bot from a YouTube video, only to realize the code was outdated. Rewrote it all with help from the Discord.py community and docs—shoutout to them, they’re awesome. I hooked up a MongoDB database (my first go at that; SQL might’ve been smarter for RPG bots, though). I also made a private music bot for the support server. The RPG bot eventually hit 350 servers, which was insane. I had to shut it down later because VPS costs were no joke, but those all-nighters fixing bugs and pushing updates? Pure adrenaline.

Now, let’s talk about my laptop—a total potato. Intel i3 2nd gen, 2GB RAM, 300GB HDD. On which my smart pants slapped Windows 10, and there was no turning back. It lagged hard, especially during online classes. In 2022, I upgraded to 4GB RAM and a 120GB SSD, and it was like night and day. Finally, I could run Node.js without it crashing—time for web development! A Discord friend was into it, and it looked dope. Before the upgrade, Node.js would’ve made my laptop weep.

I’m a weeb, so I found this GitHub repo for an anime streaming site using scraping APIs. I forked it, messed with it, and Googled everything I didn’t get (with ai this step is much faster now). Tweaked the UI to my taste and learned Next.js along the way. It took months, but it paid off. I grabbed a domain from the GitHub Education Pack for my portfolio and used a subdomain for the streaming site. (No worries it won’t work now.)

In 2023-24, I built more websites: one for my story drafts, a TikTok-style site for anime pics, a customizable new tab page and a few others. This year, I dipped into extension development with WXT and made Monochromate—a simple tool that grayscales webpages to cut screen time. It was a fun way to learn how extensions work.

Right now, I really want to dive into app development, but my laptop’s holding me back. Compiling the Flutter dev environment took 7 minutes, and Android Studio might actually kill it (There’s also React Native but I want to learn something new). I’m saving up for an upgrade. This potato laptop—13 years old and something that was built to last—turned me into a developer. I’m grateful for it; most of my classmates didn’t even have one, and it let me explore stuff they couldn’t. Huge thanks to my friend, too—they kept my curiosity alive and pushed me into new territory every step of the way. I’m also stoked about AI and agents, but one thing at a time.

I would love to read your stories in the comments and if you want to fuel my next upgrade you can buy me a coffee!!

Thanks for reading!

Originally published on my Substack