Research and the brief

Before writing a single line of code, Builderthread researches the live web so your product plan is based on real market gaps, competitor pricing, and customer complaints rather than guesswork.

How Builderthread researches your market

When you submit an idea or paste a product URL, Builderthread investigates the market in two ways at the same time:

Visits live product pages: Builderthread opens the product's website (or competing products in your space), reading the homepage, pricing page, features page, and about page to capture how existing tools work and what they charge.
Runs Google searches across multiple angles: Builderthread searches Google for competitor plans, upgrade limits, alternatives, recent launches, and real user reviews and complaints on Reddit, Hacker News, G2, and app stores.

Research runs in the background and finishes in about three minutes. Every finding links directly to the web pages Builderthread visited so you can verify any claim in one click.

Starting from an idea vs a competitor URL

You can start a project from a rough idea in your head or from an existing product you want to beat:

Start from an idea: describe what you want to build and who it is for. Builderthread searches Google and visits existing tools in that category to uncover how people solve the problem today, what current options cost, and where they fall short.
Start from a product URL: paste the link to a product you want to improve on. Builderthread visits the product's key pages, researches its reviews and alternatives on Google, and maps out its features, pricing tiers, and weak spots.

In both cases, Builderthread handles the research without asking you to fill out questionnaires. Any assumptions it makes are listed clearly in the brief so you can review or adjust them.

What is inside your brief

Your research brief gives you and your coding agent a complete picture of what to build and why:

1. Problem, buyer, and positioning

Problem and target customer: who buys in this category, the job they are trying to get done, and the workarounds they rely on today.
Differentiating wedge: the specific angle that makes your product sharper, faster, or easier to adopt than existing options.

2. Competitor breakdown

Existing alternatives: the main products in the space and where each one falls short.
Feature inventory: capabilities existing products offer, grouped by area, so you can decide what to match, skip, or improve.
Pricing tiers and limits: real plan names, prices, billing units, and the usage caps that push users to upgrade.
Repeated pain points: frustrations and unmet needs in users' own words, with direct links to the reviews and forum threads where they were found.

3. Your MVP blueprint

Core MVP features: five to ten high impact features for your first release, each tied to a real user pain point and written with clear "done when" criteria.
Personas and key user flows: the step by step journeys users take through your product.
Data records and integrations: the core records your app will store in its database and any external services it needs.
Assumptions and scope boundaries: risky assumptions to keep in mind and features intentionally left out of version one so you ship faster.

Once your brief is ready, you can read through the cited sources, edit any section, and click Approve to generate your starter repository and living PRDs. The number of web sources included in each research run depends on your plan (shown on the pricing page).