A doc that isn't afraid to disagree with itself.
When an AI writes something confidently, that's exactly when it deserves a second look. Scoped disagrees with itself before you have to.
Product AI
AI Agent
Built & Shipped
How a PRD tool ended up arguing with itself
It should feel like magic. That's the promise in every "use AI to 10x your workflow" reel — type a prompt, get a PRD, hand it to Lovable, done. I tried it once. It worked exactly as advertised, and that was the problem. So I built the tool that stops to ask questions instead.
I designed it, built it, and shipped it.
Try it live.
01
13 structured sections per
PRD, not a single paragraph
02
5 features no other AI PRD tool
I tried has
03
1 week, idea to deployed
product
Scoped is an AI-powered PRD generator — but the interesting part isn't the generation, since plenty of tools already do that well. The interesting part is what happens after: it looks at its own output and tells you where it doesn't hold together, reframes itself for whoever's reading it, and hands off directly into the tools you'd actually use next.
Phase I
Building the generator
The first version was simple by design: take a 2-3 line idea, return a structured PRD — problem statement, goals, personas, user stories, feature list. I built it as a Claude API call wrapped in a React frontend, deployed it, and it worked on the first real test. That was also exactly when it stopped being interesting. A tool that only generates is a slightly nicer version of copy-pasting a prompt into a chat window.
The problem: Every AI PRD tool I looked at — including my own first version — makes the same quiet assumption: that a document which reads finished is finished. Nothing checks whether the stated goals agree with the stated scope. Nothing acknowledges the PRD is usually a dead end — read once, then rewritten by hand into whatever a prototyping tool or coding agent actually needs.
So I stopped trying to make it write better PRDs. I made it argue
with the ones it already wrote.
Phase II
Pushing past the tutorial
This is where the real build started. Four features, in order of how much they changed what the tool actually was: a Library so PRDs persist instead of vanishing on refresh; section-level Refine so one part can be rewritten without regenerating the whole doc; Audience Mode so the same PRD reframes for engineering, execs, or design; and Scope Tensions — the smallest addition in the whole build, a few extra lines in the prompt asking the model to name the fight nobody planned for. That one ended up being the whole point.
The redesign
"I hate it"
The first visual direction was a blueprint — grid lines, corner brackets, mono-spaced labels, like an engineering drawing. Precise, deliberate, completely wrong. A PRD isn't a technical spec you measure, it's closer to something catching light from a few angles at once — which is where the frosted glass and the drifting color came from.
Before
After
Solving it
Three features, in detail
01.
Scope Tensions
Every other tool stops the moment the PRD is generated. This one keeps going — it re-reads its own North Star and its own MVP scope and names where they contradict each other. A real trade-off a PM has to make, surfaced automatically instead of caught three sprints later.
02.
Audience Mode
The same PRD reads differently depending on who opens it. One click rewrites it three ways: engineering-first, a one-page executive summary, or a design brief leading with personas and user stories.
03.
Agent Export & Prototype Prompt
A PRD only a human can act on is half-finished now. One button turns it into a CLAUDE.md-style spec for a coding agent. Another turns it into a tailored Lovable/v0 prompt, built from the PRD's actual features.
What Changed
Open Claude, write a prompt by hand, copy the output, hope it holds together, manually rewrite it for whoever reads it next.
Before
One input, a 13-section PRD, a built-in critique of its own scope, one click to reframe, one click to hand off.
After
HOW I TESTED IT
Running it on something real
Building a PRD generator is one kind of proof. Using it to build something is a harder kind. I ran a real idea through it — a group food-ordering feature — and took the generated PRD straight into Lovable with no editing.
HOW I TESTED IT
Running it on something real
Building a PRD generator is one kind of proof. Using it to build something is a harder kind. I ran a real idea through it — a group food-ordering feature — and took the generated PRD straight into Lovable with no editing.
HOW I TESTED IT
Running it on something real
Building a PRD generator is one kind of proof. Using it to build something is a harder kind. I ran a real idea through it — a group food-ordering feature — and took the generated PRD straight into Lovable with no editing.
HOW I TESTED IT
Running it on something real
Building a PRD generator is one kind of proof. Using it to build something is a harder kind. I ran a real idea through it — a group food-ordering feature — and took the generated PRD straight into Lovable with no editing.
HOW I TESTED IT
Running it on something real
Building a PRD generator is one kind of proof. Using it to build something is a harder kind. I ran a real idea through it — a group food-ordering feature — and took the generated PRD straight into Lovable with no editing.
Reflection
The hardest part of this build wasn't the generation, the deployment, or even the redesign — those were execution, even when execution meant fighting GitHub's folder structure for an hour. The hard part was deciding to let the tool undercut its own output on purpose. It's easy to ship a feature that makes a tool look smarter. It's harder to ship one that makes the tool's own PRD look less finished — and trust that a document willing to disagree with itself is more useful than one that just sounds confident.
Try it live.