You don't need months of research to figure out whether something is worth building.
Sometimes, a few searches are enough.
Search for the problem you want to solve. Search GitHub. Search Google. Search Reddit. Look at popular repositories and existing products.
If you can't find a good solution near the top of the search results, that's a signal.
It doesn't automatically mean you've discovered a billion-dollar idea. But it can mean there is something worth exploring.
And if the existing solutions are incomplete, complicated, abandoned, or simply don't solve the problem well, that's even more interesting.
Don't Wait for Someone to Give You Permission
One mistake builders make is assuming that if a project isn't already popular on GitHub, it must not be worth building.
That's backwards.
Popular repositories represent things that have already gained attention. They don't represent every useful thing that should exist.
There are opportunities hiding in:
- Better developer experiences
- Missing integrations
- Niche use cases
- Simpler alternatives
- Better documentation
- Faster tooling
- More opinionated solutions
- Tools for specific communities
You don't always need to invent something completely new.
Sometimes you just need to build the thing that people keep searching for but can't find.
A Few Searches Can Save You Months
Before spending six months building something, do some basic research.
Search for the exact problem.
Search for different ways someone might describe it.
Search GitHub repositories.
Search discussions.
Search existing products.
Then ask yourself:
"If I wanted this today, would I immediately find a great solution?"
If the answer is no, you may have found an opportunity.
Not certainty.
An opportunity.
That's enough to start.
If You're Building a Startup, Get Users Early
If your project isn't open source, don't wait until everything is polished before showing it to people.
Build a small version and get it in front of potential users.
You don't need thousands of users.
You need enough people to determine whether someone actually cares.
Once people start using the product repeatedly, recommending it, asking for features, or getting annoyed when it breaks, you've got something interesting.
That's when you should start taking distribution seriously.
Start figuring out:
- Where your users hang out
- How they discover products
- What content attracts them
- Which communities matter
- Whether referrals work
- Whether SEO can work
- Whether partnerships make sense
- Whether outbound works
- Whether the product itself can drive growth
Distribution should become a serious focus once you see evidence that people actually want what you've built.
If You're Open Source, Use the Ecosystem as Your Test
Open source gives you another way to validate your idea.
Build it.
Publish it.
Apply to OSS programs.
Participate in hackathons.
Share it with relevant developer communities.
See what happens.
If nobody cares, that's useful information.
If developers start starring the repository, opening issues, contributing, building integrations, using it in their projects, or selecting it for hackathons, that's a much stronger signal.
You have evidence that the project is interesting to at least some people.
That's when you can start asking:
"How do I get this in front of 10× more people who would care?"
That's distribution.
Don't Be Scared of Someone Copying You
This fear stops a ridiculous number of projects from being shipped.
"But what if someone copies my project?"
They probably can.
If someone can reproduce what you've built in a few months, you should still ship.
Because while they're copying you, you can be:
- Building an audience
- Getting users
- Improving the product
- Fixing problems
- Building integrations
- Creating documentation
- Attracting contributors
- Building relationships
- Finding customers
The goal isn't to create something that nobody else could ever reproduce.
The goal is to move faster than everyone else.
A competitor having the same codebase six months from now doesn't erase the six months of learning and distribution you've already accumulated.
Don't Try to Be Perfect
Your first version doesn't need to be beautiful.
It needs to exist.
Your documentation might be bad.
Your API might change.
Your UI might look rough.
Your architecture might eventually need to be rewritten.
That's fine.
You are not trying to build the final version on day one.
You are trying to get something into the hands of real people.
Because real users give you information that months of thinking cannot.
They show you:
- What actually matters
- What doesn't matter
- What is confusing
- What they desperately want
- What they don't care about
- Who your real users are
Execution is a form of research.
The faster you ship, the faster you learn.
Someone Else Might Have the Same Idea
You should also accept that your idea probably isn't unique.
Someone else may already be thinking about it.
Someone else might start building it tomorrow.
That doesn't mean you should stop.
Ideas are cheap.
Execution is where things get interesting.
Two people can have exactly the same idea and end up with completely different outcomes.
One ships in three weeks.
The other spends six months planning.
One talks to users every day.
The other builds in isolation.
One publishes consistently.
The other waits for perfection.
One keeps improving.
The other gives up.
The idea was never the whole game.
Execution Speed Is the Advantage
Imagine two developers discover the same problem.
Developer A spends six months trying to make the perfect product.
Developer B ships an ugly but useful version in three weeks.
Developer B now has five months of additional information.
Users have given feedback.
The product has improved.
The positioning has become clearer.
People have started talking about it.
Maybe contributors have appeared.
Maybe the first customers have arrived.
Maybe the developer has built an audience.
Now Developer A finally launches.
But Developer B has already moved several steps ahead.
That's the power of execution speed.
Speed creates a feedback loop:
Build → Ship → Get users → Learn → Improve → Distribute → Repeat
The faster you can repeat that loop, the faster you can discover whether you're onto something.
When Should You Start Nailing Distribution?
Not when the product is perfect.
Not when you have thousands of users.
And definitely not after you've spent a year hiding in development.
Start when you have evidence of interest.
For a startup, that might be your first group of users repeatedly getting value from the product.
For open source, it might be contributors, users, stars, hackathon recognition, OSS programs, integrations, or developers talking about what you've built.
Once you see that signal, don't just keep adding features.
Start pushing the thing.
Build the audience.
Find the communities.
Improve the onboarding.
Create content.
Talk to users.
Make distribution part of the product.
Because building something cool is only half the job.
The other half is making sure the people who need it actually find it.
And you don't need to be first forever.
You just need to start executing before everyone else does.
#startup #opensource #showdev #buildinpublic
Top comments (1)
The "annoyed when it breaks" line is the real distribution signal most people wait for growth metrics when repeat-use friction shows up way earlier. i use Viewfy for catching where people are allready asking for this stuff, and search console for confirming they found me first. That order matters more than most founders admit.