ShouldBuild Turns Market Chatter Into Product Decisions

A founder can spend weeks building a feature, launch it, and discover that the people they hoped to serve were never asking for it. The warning signs may have been visible in public reviews and forum posts, but finding and sorting through them by hand is slow work. Interest on a landing page is not the same as a reason to pay.

ShouldBuild is built around that gap. It analyses public conversations about a market and turns them into a report intended to guide product decisions. The central question is not simply whether an idea sounds good. It is whether the market shows a problem worth pursuing, which alternatives already exist, and what an early product might do differently.

The problem it is trying to solve

ShouldBuild is aimed at early SaaS founders, startup founders, and small teams making decisions with limited evidence. The product presents market research as a way to reduce guesswork at several stages: checking an idea before development, choosing features while building, and finding new opportunities after launch.

That matters because the usual evidence is often weak. Likes can indicate curiosity rather than demand. Traffic can arrive without sign-ups. A list of feature requests can reflect the loudest users instead of the most important problems. The product's premise is that repeated complaints, praise, and workarounds across existing conversations provide a better starting point.

This is customer discovery through existing public discussion rather than a survey or a sequence of interviews. That makes it potentially useful when a founder has a broad idea but no users to contact yet. It also makes the quality of the result dependent on whether the relevant market is visible in the sources it uses.

What an analysis produces

The workflow shown for ShouldBuild starts with a workspace containing previous analyses and an option to begin a new one. Completed projects receive a report with a build recommendation, market signals, pains, praises, competing products, and a view of the category. The examples on the site show conclusions such as building with caution, narrowing an idea to a specific customer group, or deciding that a market is not worth entering.

The stated sources include Reddit, Product Hunt, App Store reviews, Google Play reviews, and Hacker News. ShouldBuild says it looks for patterns across those conversations rather than treating a single comment as proof. The resulting report is intended to cover several practical questions:

• Which problems recur often enough to deserve attention?
• How do people react to existing tools?
• What gaps or opportunities appear in the category?
• Which features should be prioritised?
• Who might become an early customer?

The landing page also shows a report with a prioritised roadmap, evidence search, competitor breakdown, sentiment, and recommended pricing. Some of these capabilities depend on the selected plan. The product has a free plan with a paid upgrade, so it can be tested before a team commits to using it as part of its research process.

Where it fits in a founder's process

For an idea-stage founder, the useful output is a more focused decision about whether to build at all. A broad concept such as a new productivity app may encounter established tools and weak complaints. A narrower observation, such as a recurring problem among a particular type of agency, may provide a more defensible direction. ShouldBuild's examples place this distinction at the centre of the report.

For a team that is already building, the tool is positioned as a way to prioritise the next feature instead of relying entirely on internal preference. For a launched product, it claims to track new signals, competitive feedback, and possible markets over time. In all three cases, the proposed value is decision support, not implementation. It will not write the feature, contact a lead, or replace the work of testing whether people will actually pay.

That distinction is important. A report can help a team choose a hypothesis, but validation still requires direct contact, a usable product, or some other test of behaviour. Public complaints can reveal frustration without proving that the complaint is urgent, common among your intended customers, or commercially valuable.

The important limits

The most obvious limitation is the data boundary. ShouldBuild is presented as an analysis of public reviews and conversations. It does not appear to collect private customer interviews, survey responses, internal support tickets, or your own product analytics as part of the described workflow. If your market is poorly represented on the listed platforms, the report may have little to work with. If the category has lots of discussion from hobbyists but few paying buyers, volume can also be misleading.

The product is also not a guarantee of demand. Its build or no-build verdict is an input to a decision, not evidence that customers will arrive. Founders still need to check the specific audience, test an offer, and judge whether the recommended problem fits their ability to serve it.

ShouldBuild makes the most sense for a small team trying to replace an early gut decision with a structured look at existing market evidence. It is less suitable for a founder who already has rich first-party data, needs confidential research analysed, or expects software alone to validate an idea. Its value is in narrowing what to investigate next, not in removing uncertainty from product development.