@steipete was an indie hacker until OpenClaw reached 100k Github stars. Here’s how you can get your first thousand.
But first - when a metric becomes a goal, it ceases to be a good metric.
Stars shouldn’t be a metric you optimize for - no amount of GitHub Stars are worth a single paying user. Regardless, if your business model is based around selling hosting for your dev tool, stars can help establish legitimacy and social proof that you can then convert to sales.
I’m the creator of Open Interface which is an open source computer use app (much like Claude’s Computer Use but it preceded it by almost a year). It's cross-platform, supports multiple LLM providers, and runs natively instead of in a VM.

Marketing.
There are a few free marketing channels that I know of accessible to indie hackers: Reddit, Indie Hackers itself, Product Hunt, Twitter, and HackerNews. For the bulk of my projects Reddit is what has generally brought me the most eyes and adoption, and it was no different for Open Interface.
There are other exhaustive lists you can search for on IH but some of the popular and effective subreddits are:
Besides these you can dive into some specific communities that only you and your business can know.
My biggest marketing push, for example, came from a lackluster post on /r/OpenAI that blew up with 143K views and almost 500 shares. That single post fueled my project’s growth for many months with its SEO as well as the network effects of Github.

You can push for other marketing strategies such as Youtube videos, blog posts, and collaborations with other dev tools depending on your evaluation of expected returns. Press coverage has also worked well for me in the past.
Before its marketing, we had to make sure that the quality of the repository merited attention. Below are a few steps you can take to improve the quality of your repository
Have an inviting README:
How? Do the things you would generally do to write a compelling document on the internet - add a narrative, include illustrations, a demo, some statistics.
A lot of successful READMEs go the route of being a very technical and all inclusive documentation of the project. I personally didn’t think it would have lended well to this project or reflect my voice so I kept it a light and accessible read.
Let your document breathe.
Here are a few things you should consider adding to your READMEs to make them more scanable:

Github README Badges
This one’s a personal choice and many might consider it distracting for the technical nature of a Github README, but I believe badges give the document a pop of color and some breathing space between walls of texts.
It’s about your voice and taste, so if it feels appropriate you can generate them at https://shields.io/badges.

Demo
There are more than a few fancy screen recorders out there for MacOS (Screen Studio is one I saw recently on IH), but I stuck to a simple screen recording (⌘Cmd + ⇧Shift + 5) that I edited and converted to a GIF using moviepy. In general I prefer GIFs to embedded videos, but it can be very contextual.
It is important to make sure your demo conveys its point across swiftly and memorably because right now there is a lot of activity in the dev tool space that can drown out your business.



Use your GitHub Stars as a form of currency to buy things that will help you monetize - whether it is legitimacy to sell hosting, or entry into pitch competitions, or cross marketing your other products. I myself am trying to figure it out what works best for me.
Happy hacking!
Great breakdown, Amber — your focus on trust-building details over vanity feels exactly right. Did you see this point: founders who publish concise before/after evidence (benchmarks, handoff logs, failure fixes) tend to attract a lot more practical follow-through than hype-only posts. If useful, you can see our similar trust-first validation framing at https://www.clawbarter.com
Great breakdown, Amber — especially the reminder that stars are trust fuel, not the finish line.
Did you see this week’s wave where founders started posting side-by-side “before vs after OpenClaw handoff” logs to prove reliability instead of just saying “works now”? That proof-first shift feels huge.
If you’re curious, we’re running live agent-to-agent verification tests here: https://www.clawbarter.com
Great breakdown—especially the point that stars are a trust signal, not the end goal. Your README/demo/upkeep framework maps well to AI agent products too, where visible proof loops usually outperform hype. We’re currently testing autonomous agent-to-agent trading. Would you like to have your agent join a live test? https://www.clawbarter.com
GitHub Stars as social proof is a great idea, and Reddit users might be more willing to give a star to an open source project than take a SAAS sales pitch
It's great, but Reddit is so strict that posts get ban all the time, which is a nerve-wracking thing...
@AmberSahdev Did you work on your Reddit’s karma to use this channel as a way to promote your project, didn’t you?
@ph7 oh that's a good point. I didn't work on my Reddit Karma, my project posts are the only things I have on the account. Guess I've lucked out and slipped under the radar so far.
Great article! Thank you!
As someone working to build a digital presence and attract collaborators for a few open-source side projects, I found those tips invaluable. Just embedded a star count graph in one of my repos!
Wonderful article. Thanks man
A quick question: how do you strike the balance between growing the user base and addressing feature requests or bugs without feeling overwhelmed?
I have to say I've never really payed attention to the starred section in a github repository. I generally look for code that is well maintained (updated regularly, bugs fixed, documented well, questions answered) and has recommendation from the community for which it supports. I know getting the recommendations at first can be difficult.