DEV Community

Cover image for From 0 to 100 GitHub Stars with a Python CLI (Spoiler: It's Not as Easy as They Say)
Tlaloc-Es
Tlaloc-Es

Posted on

From 0 to 100 GitHub Stars with a Python CLI (Spoiler: It's Not as Easy as They Say)

“You’ll get 1000 GitHub stars in a few months.”

No.

At least, that wasn’t my case.

This is the real story of spending over a year building Killpy, a tool to clean Python projects… and everything I learned trying to get someone—anyone—to use it.


It all started with a slowly dying hard drive

If you work with Python, this will sound familiar:

  • .venv everywhere
  • abandoned projects
  • huge libraries like PyTorch, Pandas, NumPy
  • endless caches: __pycache__, .pytest_cache, .ruff_cache, .mypy_cache

And without realizing it…

👉 5GB here

👉 3GB there

👉 another forgotten .venv

Until one day you check your disk and think:

“What the hell is taking all this space?”


Déjà vu: Node already solved this

When I worked with Node.js, I used:

👉 npkill

And it was magic.

You could select node_modules folders and free gigabytes in seconds.

Because let’s be honest: Node can install half the internet to do something absurdly simple 😅


The problem: Python had no clear equivalent

Yes, you can use find.

Yes, you can write scripts.

Yes, you can clean things manually.

But everything felt:

  • repetitive
  • fragile
  • not reusable
  • inconvenient

And most importantly…

Nobody had really solved this properly as a real tool.


That’s how Killpy was born

So I decided to build what I was missing.

A CLI tool to:

  • delete .venv
  • clean caches (__pycache__, .ruff_cache, etc.)
  • analyze disk usage
  • detect heavy dependencies
  • integrate with pre-commit

Basically, a “npkill for Python”… but more powerful.


First result: 20GB freed

The day I finished it and ran it on my machine:

👉 I freed ~20GB

Literally.

Enough space for more models, datasets… or just more chaos.


Goal: 100 stars ⭐

I didn’t want to go viral.

I just wanted:

  • feedback
  • users
  • contributions
  • validation

And yes, the famous 100 stars.


Phase 1: Following “the rules”

I shared it on:

  • Dev.to
  • LinkedIn
  • Reddit

Result:

👉 ~35 stars in 1 month

Good… but far from the “magical organic growth.”

I also tried getting it into “awesome” lists.

Result:

👉 PR open for almost 1 year

👉 Closed for not having enough stars


The big question

Why does something like npkill work great in Node…

…but doesn’t take off the same way in Python?

Because the problem definitely exists. A lot.

In Python:

  • every project has its own environment
  • you can have 10 active repos
  • ML + data = constant gigabytes
  • .venv grows out of control

And still… lower adoption.


Phase 2: Make it better

After some time without touching it (work 😅), I came back with:

  • a major refactor
  • better documentation
  • optimized README
  • some SEO improvements
  • new features

Then I repeated distribution:

  • Dev.to
  • Reddit
  • LinkedIn
  • Hacker News

Result:

👉 +80 stars in 1–2 months

Much better.

But…


The internet being the internet

Reddit

“This is AI”

Tried to engage → more criticism → thread closed 🤷


LinkedIn

  • super organized people: “I clean everything manually”
  • others who loved the idea

Mixed reactions.


Hacker News

  • some traffic
  • a few stars
  • one real contribution 🎉

That moment when someone:

  • reads your code
  • finds a bug
  • opens a PR

That’s the good stuff.


What NO ONE tells you about stars

❌ They don’t come magically

Posting once is not enough.

❌ They don’t come just from usefulness

You can solve a real problem… and still go unnoticed.

❌ They don’t come “in X months”

At least, not always.


What I DID learn

✔️ 1. Visibility = repetition

Posting once doesn’t work. You have to keep showing up.

✔️ 2. Community changes everything

The same tool can:

  • thrive in one ecosystem
  • be ignored in another

✔️ 3. Open source can be draining

Promoting something free… and getting hate… isn’t trivial.

✔️ 4. Contributions > stars

Going from:

  • “no one contributes” to
  • “someone took time to improve your project”

That’s a huge leap.


What’s next?

The plan:

  • try again with awesome-python lists
  • keep iterating
  • improve features
  • share it again

But with a different mindset.


Final thoughts

Maybe:

  • my experience is anecdotal
  • I’m doing something wrong
  • or the common narrative is just inflated

But my conclusion is this:

A project doesn’t grow on its own.

Not even when it’s useful.

It needs:

  • visibility
  • persistence
  • context
  • and a bit of luck

And you?

If you’ve gone through something similar:

  • How long did it take you to reach 100 stars?
  • What actually worked?
  • What would you never do again?

I’d love to read your experience 👇

Top comments (0)