Requirements ready for review

Say what is out of scope,
then what is in scope.

Turn a requirement draft into a PRD with context, goals, non-goals, scope, solution, and acceptance criteria. Schedules, resources, and research data that are not decided stay as “to be decided”. We do not fill them in for you.

Non-goals requiredOpen means openCheckable acceptance
01

Paste draft

0 / 12,000 charactersMinimum 80

Content is used only for this AI request and is not intentionally stored by this site.

02

Review the PRD

Your result will appear here

We write the problem before the solution, add a non-goals section, turn vague requests into checkable acceptance criteria, and list every open item.

SAMPLE OUTPUT

Here is exactly what you receive.

This is the complete output for the source text in the demo above: a completeness score, itemised revisions, what was marked open and why, items to confirm, and the drafted PRD. It is a demonstration, not a customer case.

SAMPLE

Draft result (sample)

Completeness score88/100
+50
01

Add the non-goals section

The draft had no boundary at all. Three proposed non-goals — cross-account aggregation, custom charts, and scheduled delivery — were derived from the stated scope and marked as not yet agreed.

02

Turn “as soon as possible” into an open schedule

The source demanded a fast ship date without giving one. The schedule section now states that this document does not estimate effort, so a verbal request cannot become a written commitment.

03

Convert subjective requirements into an acceptance structure

“Looks good” and “simple to use” cannot be judged. They become a given / action / observable-result structure, with the metric list and experience criteria listed as still needed.

Drafted PRD
# Data dashboard — product requirements (draft)

## Context
Users currently cannot see their own data in one place and have to assemble it manually to understand usage.

TODO: the specific situations where this occurs, the user types involved, and how it is handled today are missing; add them before fixing the scope

## Goals
- Users see their core data on a single page without assembling it themselves.

## Non-goals (required section)
- No cross-account or cross-team aggregation.
- No custom chart building.
- No scheduled email delivery.

These are proposed from the stated scope and are not yet agreed.

## Scope
- The dashboard page and the display of core metrics.
- Export: to be decided — format and data volume limits need confirmation.

## Solution
To be decided: the metric list and data sources must be confirmed first.

## Acceptance criteria
- Given: the user is signed in and has historical data.
- Action: open the dashboard page.
- Result: the page shows every metric on the agreed metric list.

TODO: metric list, data sources, and judgeable criteria for “looks good” and “simple to use” all need to be supplied

## Schedule
To be decided: this document does not estimate effort.

WHAT DRAFTING DOES

A requirements doc exists so others can argue with you.

01

Problem before solution

State who hits what trouble and when, before describing the fix. Reverse the order and review turns into a debate about taste.

02

Write down what you are not doing

Non-goals are body text, not an appendix. Whatever you leave out, everyone fills in from their own assumptions.

03

Acceptance must be judgeable

“Feels smooth” cannot be verified. Given a state, an action, and an observable result — that is when you know it is done.

WHY IT IS WORTH DOING

Requirements without non-goals always grow.

01

Unwritten boundaries get invented

With no “not included” section, design and engineering each assume differently and the results do not meet.

02

A fake date becomes a real promise

A casual “ships in two weeks” leaves the document as a commitment, and it never went through any estimate.

03

Invented research is hardest to retract

“70% of users want this” gets quoted repeatedly once it is written down, until somebody checks the raw data.

Note: common practice for product requirement documents is to bound the problem and scope first, then discuss solutions, and close with acceptance criteria that can be judged. Teams differ in document granularity and review process. This site drafts documents only; it verifies no data and offers no product or project management advice.

DRAFTING DEMO

The same requirement, organised.

Before

Build a data dashboard so users can see their own data. The interface should look good, it should be simple to use, ship it as soon as possible, and ideally support export.

Drafted
# Data dashboard — product requirements (draft)

## Context
Users currently cannot see their own data in one place and have to assemble it manually to understand usage.

TODO: the specific situations where this occurs, the user types involved, and how it is handled today are missing; add them before fixing the scope

## Goals
- Users see their core data on a single page without assembling it themselves.

## Non-goals (required section)
- No cross-account or cross-team aggregation.
- No custom chart building.
- No scheduled email delivery.

These are proposed from the stated scope and are not yet agreed.

## Scope
- The dashboard page and the display of core metrics.
- Export: to be decided — format and data volume limits need confirmation.

## Solution
To be decided: the metric list and data sources must be confirmed first.

## Acceptance criteria
- Given: the user is signed in and has historical data.
- Action: open the dashboard page.
- Result: the page shows every metric on the agreed metric list.

TODO: metric list, data sources, and judgeable criteria for “looks good” and “simple to use” all need to be supplied

## Schedule
To be decided: this document does not estimate effort.

Demo sample: adds the non-goals section, turns “as soon as possible” into an open schedule, and converts vague experience requirements into judgeable acceptance criteria. Paste your draft to get your version (sign-in required; one credit per run).

WHY YOU CAN TRUST IT

We put “we do not set your schedule” into our product principles.

Schedule and resources stay open

Effort, ship date, and staffing are written as “to be decided”. You and your team estimate those; a document cannot decide them.

No invented user research

Survey percentages, interview quotes, sample sizes, and personas are absent unless you supply them — otherwise they become an open question.

Non-goals always appear

Even when the material is silent, we derive proposed non-goals from the stated scope and mark them as not yet agreed.

Content is not stored

Submitted text is used for this single AI request and is not intentionally persisted. See the Privacy Policy.

FAQ

Ask these before you pay.

Will you estimate the effort?

No. Schedule, milestones, staffing, and budget are written as “to be decided”. Once such a number lands in a document it reads as a commitment, and estimating is work for you and your team.

What if I never mentioned non-goals?

We derive proposed non-goals from the scope you did describe and mark them clearly as not yet agreed. Non-goals are body text and cannot be omitted.

What if acceptance criteria cannot be written?

We say the requirement is not judgeable as stated, turn subjective wording like “looks good” into the specific criteria still needed, and list them for confirmation.

What does one draft cost?

One credit per run, usually done in seconds, returning the PRD, revision notes, and open items.

Do credits expire?

No. Credits never expire — whatever you do not use carries over to the next cycle instead of resetting.

Is there batch processing or an API?

Not yet. Each run processes one document and consumes one credit; there is no bulk upload or API today. Email us with your use case and we will assess it.

Is my content stored?

Not intentionally. Text is used for this single AI request only. See the Privacy Policy.

What content fits?

Drafts for new features, notes written before a requirements review, summaries of meeting notes, written versions of a verbal request from management — any product idea that needs to become a reviewable document.

SIMPLE PRICING

Prove the value before you upgrade.

Starter

$9/ month

For an occasional publishing cadence, with a focused monthly credit allocation.

  • 50 optimization credits per monthly renewal
  • Complete GEO analysis
  • Chinese and English output
  • Markdown export

Pro

Recommended$29/ month

For frequent publishers who iterate on content continuously.

  • 250 optimization credits per monthly renewal
  • Complete GEO analysis
  • Chinese and English output
  • Markdown export

Advanced

$79/ month

Our largest monthly credit allocation, for the heaviest continuous usage.

  • 1,000 optimization credits per monthly renewal
  • Complete GEO analysis
  • Chinese and English output
  • Markdown export
Loading localized prices

Credits never expire: unused credits carry over instead of resetting. Credits apply to this site only and are not shared with other sites.

Prices shown are USD baselines; final currency, taxes, and discounts are determined by Paddle for the checkout location.