Table of Contents

I used to think my GitHub projects failed because my code wasn’t good enough. Turns out, I was completely wrong about what actually matters.

My TikTokAPI project has over 5,000 stars and 2 million downloads. But here’s the thing that still surprises me - I’ve built other projects that were technically way better, more innovative, and took me months longer to build. They got maybe 10 stars total.

After building dozens of projects over 5+ years, I’ve realized that the difference between success and failure usually comes down to 3 things that have nothing to do with how elegant your code is. And honestly, I wish someone had told me this earlier because I spent way too much time optimizing the wrong things.

The Thing Nobody Talks About

Before I get into what I learned, let me tell you about my biggest mistake. I used to build projects that I thought were cool, not projects that people actually needed.

I’d spend months crafting these elegant solutions to problems that basically only existed in my head. Meanwhile, TikTokAPI - which honestly started as a pretty messy weekend project just so I could scrape trending videos for YouTube compilations - ended up being my most successful project. And it wasn’t because the code was good (it really wasn’t at first), but because I accidentally stumbled into solving a problem that hundreds of people were already struggling with.

Rule 1: Build Something People Want

This might sound obvious, but it took me way too long to figure out: if people aren’t already searching for your solution, you’re probably building in the wrong direction.

When I started TikTokAPI, I wasn’t trying to build the next big thing. I just wanted to scrape trending TikTok videos for my own YouTube compilations. The first version was honestly pretty embarrassing - just some messy scraping logic that barely worked.

But here’s what happened that changed everything: I threw the code on GitHub and basically forgot about it. Three months later, I’m getting emails from other developers saying they’d been trying to collect TikTok data for months but couldn’t find anything that actually worked.

I had accidentally solved a problem that hundreds of people were already struggling with, and I didn’t even realize it.

Source: Google Analytics illustrating increase in organic search traffic for tiktok api

The crazy part? When I looked into it later, “TikTok API” gets around 15,000 monthly searches according to Ubersuggest. The demand was already there - I just got lucky and stumbled into it. My project has been ranking #2 on Google for “TikTok API” for over 3 years now, which explains why people keep finding it.

Source: Ubersuggest Showing 15K Monthly Searches

Rule 2: Make It Easy to Use

I learned this the hard way: every small barrier to using your project is a reason for someone to give up and move on.

It’s not bad code that kills projects - it’s friction. People will abandon your project the second they hit any roadblock, even if your code is amazing. With TikTokAPI, I started obsessing over making everything as easy as possible because I kept watching people give up.

Installation Friction

Your installation process should be copy-paste simple. For TikTokAPI, it’s two commands:

pip install tiktokapi
python -m playwright install

Done. That’s it. No git cloning, no complex environment setup, no hunting for dependencies.

I chose Python because I knew my audience (developers, data scientists, researchers) already had it installed. If TikTokAPI was written in Rust or Go, it might have been more performant, but it would have been much harder to get the same reach across my target audience.

Usage Friction

People don’t want to read documentation - they want to copy, paste, and see results. My README includes working examples that run immediately:

from TikTokApi import TikTokApi
import asyncio
 
ms_token = os.environ.get("ms_token", None)
 
async def trending_videos():
    async with TikTokApi() as api:
        await api.create_sessions(ms_tokens=[ms_token], num_sessions=1)
        async for video in api.trending.videos(count=30):
            print(video)
            print(video.as_dict)
 
if __name__ == "__main__":
    asyncio.run(trending_videos())

This isn’t pseudocode - it’s actual working code that someone can copy and have running in under a minute.

Documentation Friction

I learned that different people need different entry points, so I tried to cover all the bases:

• Quick Start: For people who just want to get something working immediately
• Examples folder: Real-world use cases that are more complex but still easy to run
• API docs: Comprehensive reference for people who want to dig deeper
• Video tutorials: For people who learn better by watching

Contribution Friction

Over 50 people have contributed to TikTokAPI, which honestly surprised me at first. But I think it happened because I tried to make contributing as welcoming as possible:

• Clear guidelines for how to contribute
• Friendly, welcoming tone in issues and PRs
• “Good first issue” labels for newcomers
• Quick response times to questions (usually within a day or two)

The result? More contributors means more credibility, more people invested in the project, and more people spreading the word about it.

The 5-Minute Friction Test

Try to run these tests on your projects:

1. Fresh Machine Test: Use a new computer/container and time how long it takes to get a working example
2. Beginner User Test: Ask someone unfamiliar with your project to try using it
3. Documentation Gap Test: Try to accomplish common tasks using only your documentation
4. Error Scenario Test: Intentionally break things and see if error messages help recovery
5. Competitive Analysis: Compare your installation/usage flow to similar projects

Friction Elimination Tools & Resources

These will vary by project, language, and so much more but here’s a few ideas:

Development Tools:

• Dev Containers: GitHub Codespaces, VS Code dev containers
• Documentation: GitBook, Docusaurus, MkDocs
• Code Examples: GitHub Gists, CodeSandbox, Repl.it
• Error Tracking: Sentry, LogRocket for understanding user pain points

Testing Tools:

• Installation Testing: Docker, GitHub Actions with multiple OS
• Documentation Testing: Vale for prose linting, link checkers
• User Testing: Hotjar, FullStory for user behavior analysis

Automation:

• Dependency Updates: Dependabot, Renovate
• Documentation Generation: Sphinx, JSDoc, rustdoc
• Example Validation: CI jobs that run all example code

Common Friction Points I’ve Noticed

From using and building a bunch of open source projects, here are the things that usually make me give up:

1. Installation Hell: Having to install 5+ dependencies manually
2. Configuration Complexity: Needing extensive config files for basic usage
3. Outdated Examples: Code examples that don’t work with current versions
4. Assumption Errors: Assuming users have specific knowledge/tools
5. Platform Bias: Only working on the developer’s preferred OS
6. Unclear Error Messages: Errors that don’t explain what went wrong or how to fix it

Rule 3: Help People Find Your Project

This one seems obvious but I see people mess it up all the time: if your audience can’t find you, your project basically doesn’t exist to them.

I used to give my projects these clever, abstract names that I thought sounded cool but helped nobody find them. “TikTokAPI” works because people literally search for “tiktok api” and I’ve been ranking #2 on Google for that for over 3 years.

But naming is just the start. I learned that you need to create multiple ways for people to discover your project, not just hope they stumble across your GitHub repo.

The Ecosystem Approach

For TikTokAPI, I ended up creating multiple ways for people to find it:

1. GitHub optimization: Added topic tags like tiktok, api, scraping, python
2. YouTube tutorials: Made several videos showing how to install and use it
3. Blog posts: Wrote detailed guides and case studies
4. Example projects: Built separate repositories showing real-world applications

TikTok API appearing in GitHub's trending repositories, demonstrating organic discoverability

The 100-Star Tipping Point

Here’s something weird I’ve noticed across my projects: there seems to be some kind of threshold around 100 stars where things start to snowball. I’m not sure if it’s GitHub’s algorithm kicking in or just social proof, but growth definitely accelerates after hitting that milestone.

Before 100 stars, every single user feels hard-earned. After 100 stars, the project starts to market itself. People find it through search, recommend it to colleagues, and actually contribute back to the community.

Why This Actually Matters

I’ve been exactly where you probably are right now. I’ve spent 6 months building something I thought was brilliant, only to watch it get 3 stars from my friends. I’ve also completely burned out on open source and wondered if it was even worth it.

But then every once in a while, someone emails me saying they used TikTokAPI for their research project. Or a teacher tells me it helped them create a more engaging curriculum. Or a startup mentions it was crucial for their market research. That’s when I remember why I started doing this - to build things that actually help people.

These 3 things aren’t just about getting more stars or downloads. They’re about maximizing the impact of your work and making sure that the time you spend building actually helps the people who need it most.

Have you applied any of these rules to your own projects? I’d love to hear about your experiences - feel free to reach out on GitHub or LinkedIn.