I Stared at Those 390 Replies and Suddenly Had No Idea What to Build
At 10 p.m. last Wednesday, I was scrolling Hacker News in a rented meeting room in Hangzhou. Someone had asked, “What have you been working on lately?” Nearly 400 replies followed. Some people were building small tools, some were tinkering with agriculture, and others just wanted quiet time to write code. My first reaction was to bookmark the thread. The next day, I felt empty: none of those projects moved me, and forcing myself to imitate one would probably have wasted my time.
I’ve also gotten stuck chasing trends. When I saw someone else gain attention for an idea, I would rush into a different market without even finding out who might pay. A lively comment section doesn’t mean it contains an opportunity that fits me.
This Isn’t a Tool List. It’s a Demand Map
At its core, this thread is a public needs interview. People openly share what they’re exploring, what problems they’re running into, and how much time they’re willing to invest. Founders can treat it as a free transcript and look for three signals: the same problem mentioned repeatedly, a workaround already in use, or an willingness to discuss paying for a solution.
I know a fictional indie developer, Lin Yue, who freelances in Beijing. On the evening of November 18, she read a complaint in the thread: designers found it annoying to manually organize brand assets for every delivery. Lin Yue didn’t start building. She messaged the person and helped organize the assets three times using a spreadsheet. She later found that this kind of need was far more concrete than “build another productivity tool,” and much easier to turn into a first small paid project.
I don’t treat “most upvoted” as “best fit.” I write down complaints that recur, then ask whether I can build the minimum viable version within a week without hiring an engineer first.
Replicating This Demand-Filtering Routine Takes Less Than an Hour
Money: ¥0. Or spend ¥30 on a coffee so I can sit down and read carefully. Time: 40 minutes reading plus 15 minutes filtering, or about one hour total. Technical barrier: knowing how to copy a link and use a spreadsheet; no programming required. First step: open the original thread, move the cursor to the comments, sort by “Newest,” and start reading.
I create three columns: exact words, clumsy workaround already in use, and person who might pay. I keep only problems mentioned at least twice that someone is already solving manually. I interview first instead of rushing to build. There’s no harm in waiting; this spreadsheet is only for organizing ideas, not quitting my job to start a company.
Choose the Next Step Based on Your Current Team Size
Just starting out: I’d pick a discussion involving a problem I’ve personally experienced and talk to about three people. I’d ask only how they solved it last week and whether they’ve ever paid for it. I wouldn’t build the full product yet.
With 1–2 customers: I’d send the problems mentioned in the thread to my existing customers and ask them to rank them. Then I’d build a rough version of the solution to the most common problem. I’d aim to keep the cost under ¥200 and deliver a manual version within three days.
Scaling up: I’d have the team collect public discussions once a week, separating problems that have merely appeared from those someone has paid to solve, before deciding which needs enter the product roadmap. Upvotes shouldn’t replace sales data.
I’m still practicing this method, and I may filter out the wrong things too. I might pick one discussion and run a single round of interviews, rather than turn it into another big project.