Building NeedSonar in Public: Month 1 - What We Learned

We started NeedSonar because we were tired of reading 200 Reddit threads a week to find product ideas. The pain was real, the cost was high, and we believed a tool could compress the loop. This is the first of a monthly series where we document what we built, what we killed, and what we learned. The goal is not to promote the product. The goal is to write down what we wish someone had told us before we started. The series is for the founder who is six months behind us and wondering if they are on the right track. The short answer is probably yes. The longer answer is in the rest of this post.

The Problem We Were Solving

Between the two of us, we had launched four SaaS products over the previous three years. Three failed. The pattern was the same every time: we picked an idea based on a friend, a tweet, or a vague trend, and we built for 6 to 9 months before realizing the buyers were not there. By the time we learned that, we had burned $40k of our own money and a year of runway. The most expensive mistake was the same every time: we thought the idea was good before we tested it. The test came after the build, and by then we were too invested to hear the answer.

We needed a way to find ideas that were already validated by the market, by people complaining in public, at scale. The communities existed. The data existed. We just did not have a fast way to read all of it. So we started building one. The first version was a Notion template and a daily habit. The current version is a product. The progression was not linear, and we made a lot of mistakes along the way. The mistakes are the most useful part of this post, because they are the ones you can avoid.

Week 1: Writing the First Crawlers

The first week was a crawl sprint. We wrote crawlers for Reddit, Hacker News, and V2EX in five days. The Reddit crawler was the easiest because the API is well-documented. The Hacker News crawler was even easier because the Firebase API is public. V2EX took longer because the API requires a token and the rate limits are tight. The rate limits were the first surprise: we hit them on day 2 and had to add a backoff. The backoff added 4 hours to the crawl time, which is fine for a daily job and not fine for a real-time feed. We chose daily.

The first bug we hit was deduplication. Reddit cross-posts the same story to multiple subreddits, and our first version stored each as a separate pain point. The fix was a content hash on the title and body, which deduplicated 18% of the early data. That one change taught us more about data quality than any blog post we had read. The lesson is that data products live or die on dedup, and the cost of getting it wrong is invisible until you try to analyze the data and the patterns are smeared by duplicates.

"If your first version of a data product does not dedupe, you have not understood data products yet." - u/olddata on r/dataengineering

The second bug was language detection. About 22% of the V2EX posts were in Chinese, and our English-only schema produced empty fields. We added a language detection step and routed non-English content to a separate pipeline with its own schema. The separate pipeline was a scope creep we did not need in week 1, but the data was already there, and ignoring it felt wrong. We now translate and score the non-English content as well, which has produced some of our best signal in niches where the English communities are quiet.

Weeks 2 to 3: First User Interviews

In weeks two and three, we ran four founder conversations. They were 30 to 45 minutes each, unstructured, and recorded. The point was to learn what the people we were building for actually did today, not to demo the product. We had a half-built version at that point but we showed it only at the end. The "show at the end" rule is the most important rule in early customer development, and the one we see most founders break.

Founder A runs a $4k MRR SaaS for therapists. He told us that he reads 5 subreddits a day and saves posts in Notion, then re-reads them on Sunday to spot themes. He said: "I would pay $50/mo for a tool that does the Sunday part for me." That quote shaped our positioning. The "Sunday part" framing became the language we use in the landing page, because it matched the mental model of the buyer.

Founder B runs an agency and was building a SaaS on the side. She was skeptical. She said: "Every AI tool I have tried for market research gives me the same generic stuff. What I want is a list of complaints from last week, scored, with the original thread linked." That quote shaped the dashboard layout. The "complaints from last week, scored" became the home view, and the original thread link became a hard requirement, not a nice-to-have.

Founder C is a serial indie founder, three products deep. He told us that the bigger problem is not finding ideas, it is deciding between three good ones. He said: "If your tool helps me kill an idea, that is more valuable than helping me find one." That feedback changed our roadmap. The "kill an idea" workflow became a feature, and the dashboard now has a dedicated view for it. The founders who use it most are the serial ones, who have a backlog of ideas and need a way to prioritize.

Founder D runs a $12k MRR tool and was our most skeptical user. He said: "I already do this with Twitter searches and a spreadsheet. Why would I pay?" We took that seriously. The honest answer was: maybe he would not. The point was that there were 10,000 founders like Founder A and only 500 like Founder D, and we should build for the A profile. The D profile is interesting but not addressable, and chasing it would have wasted months.

The Mistake: We Built a Feature Nobody Used

In week four, we shipped a feature called "Competitor Tracker." It monitored mentions of specific products in the crawled posts and surfaced them as a watchlist. We thought it was clever. We spent nine days on it. We launched it. Zero users clicked it in the first two weeks. The usage data was unambiguous. The qualitative feedback was unanimous. The feature was a miss.

We were confused. We interviewed two of the four founders again. Both said the same thing: "I do not need to track competitors, I need to track problems." The feature solved a problem we imagined, not one they had. We killed it. The lesson, written in our team wiki, is now: if a feature cannot be traced to a specific founder quote, it does not ship. The rule has been violated twice since, and both times the feature failed. The rule is now treated as a hard gate.

The deeper lesson is that founders build features that scratch their own itch, and the itch is often different from the buyer's. The Competitor Tracker was our itch. We wanted to know when someone mentioned our product. That is a legitimate need, but it is a need for us, not for the buyer. The buyer's need was for problems, not for products. The mistake was conflating the two.

What We Kept, What We Killed

We kept the pain-point dashboard, the per-community breakdown, the daily digest email, and the search bar. We killed the competitor tracker, the sentiment-only view, and the team collaboration features. The team collaboration features felt important in theory but no solo founder we spoke with had asked for them, and the development cost was 3x what we estimated. The cost overrun was its own lesson: never estimate a feature without talking to a buyer first. The estimate will be wrong in the direction of optimism.

The decision rule we adopted was simple: ship the smallest set of features that 80% of our target users would use weekly. Anything below that bar waits. The 80% number is itself a guess, but it is a guess that has held up over 6 months. The features that meet the bar are the ones that appear in the weekly digest. The ones that do not are candidates for cutting.

The weekly digest is the most important feature we ship. It is the only feature that all four founders said they would use. The dashboard is the second. The search bar is the third. The per-community breakdown is the fourth. Everything else is below the bar and is on a list that we review every two weeks. The list is currently 11 items long and growing faster than we are cutting from it.

The Three Metrics We Now Track

We picked three metrics to focus on in month one. We chose them because each one tells us whether a different part of the system is working.

• Daily active pain points scored - the number of unique pain points our pipeline scores per day. If this is below 200, our crawlers are broken or the communities are quiet.
• Weekly returning users - the number of users who come back to the dashboard in two different weeks. If this is below 30% of sign-ups, the product is not sticky.
• Free-to-paid conversion - the number of free users who upgrade in the first 30 days. If this is below 2%, the pricing or the value prop is wrong.

In month one, daily pain points scored averaged 340, weekly returning users was 24%, and free-to-paid was 1.4%. Two of the three are below target. The plan for month two is to fix the returning-user number, which we believe is an onboarding problem, and the conversion number, which we believe is a pricing problem. The order matters. Onboarding is the foundation. Pricing is the conversion mechanism. Fix the foundation first.

The metric we explicitly chose NOT to track is total sign-ups. Sign-ups are a vanity metric. They tell you nothing about whether the product is working. A product with 10,000 sign-ups and 0% conversion is a product with no business. A product with 200 sign-ups and 30% conversion is a product with a real business and a distribution problem. We have the second profile. We are working on the distribution problem now.

What Month Two Is About

Month two is going to be about pricing. The original pricing is per-seat at $29/mo, and we suspect it is the wrong shape for solo founders. We have a hypothesis that usage-based pricing with a free tier will convert better, and we are going to test it. The next post will walk through what we tried, what worked, and what we killed. The honest version, with the numbers and the mistakes.

The other thing month two is about is humility. We assumed we knew what the buyer wanted. We were partly right. The remaining part is what we are about to learn. The lesson of month one is that the buyer is smarter than the founder, and the data is more honest than the deck. Trust the data. The deck will follow.

If you want to follow along, we post monthly updates on the blog and ship in public.

Try NeedSonar free