understand · brief intake
Website analysis
What the site says, with evidence.
In Brief intake
It is the cheapest evidence in the brief and the weakest, so it has to be honest about that.
Quote, then claim.
Every field stores the exact sentence and URL it came from. A field with no quote is a guess and is labelled one.
The site is a claim.
What a homepage says about its own customers is marketing. It enters as a site claim, never as customer evidence.
Re-read, don't overwrite.
Site facts are re-read on a schedule. The founder's own corrections live beside them and never get replaced by a re-read.
what it is
Reading a product's front door, in industry terms
Industry names: website analysis, positioning audit or messaging teardown. In a sales team it is the account research a rep does before the first call. Here it is automated and its output is structured: the product block and the price block of the brief.
It answers the questions the rest of the pipeline can't start without: is there something live to point people at, what stage is the product in, what does it claim to do and for whom, what does it cost, and what proof does it show. It does not answer who actually pays or why. Those need payers, signups or the market.
Product stage — the first field · waitlist, live with no signups, live with signups, paying, growing. Decides which playbooks and offers are even possible.
Value proposition — positioning · the job the product does, in the site's words, plus the buyer it names.
Pricing — price and plans · public price, plans, trial or free tier, checkout versus book-a-demo.
Social proof — proof · testimonials, logos, counts, case studies. Read as claims until a payer confirms them.
The model never upgrades it on its own.
Front door — the real entry page · the page a stranger should land on: homepage, pricing or waitlist. Sometimes not the URL the founder pasted.
how it works
From a pasted link to the product and price blocks
The run takes about a minute in a sandbox. Each step is cheap before the next one is expensive, and each one leaves a record so a wrong field can be traced to the page and sentence that produced it.
- Resolve the front door — follow redirects, find the homepage, pricing, waitlist
- Fetch the pages — home, pricing, about, docs, integrations, changelog
- Classify the stage — waitlist form, signup, checkout, customers page
- Extract fields — job, buyer, category, price, proof, integrations
- Attach the quote — exact sentence + URL for every field
- Label the evidence — site claim by default; status observed or inferred
- Flag the gaps — fields the site can't fill become interview questions
- Hand to the founder — confirm, correct or reject each field once
- Resolve the front door — follow redirects, find the homepage, pricing, waitlist
- Fetch the pages — home, pricing, about, docs, integrations, changelog
- Classify the stage — waitlist form, signup, checkout, customers page
- Extract fields — job, buyer, category, price, proof, integrations
- Attach the quote — exact sentence + URL for every field
- Label the evidence — site claim by default; status observed or inferred
- Flag the gaps — fields the site can't fill become interview questions
- Hand to the founder — confirm, correct or reject each field once
the one rule that matters
The extractor may say "the site says X". It may not say "customers do X". That sentence needs tier A or B evidence, which only payers, signups or the market can give.
the object
A brief field read off the site
Each field is its own row, not a paragraph. That is what lets the founder correct one line, lets a re-read change one line, and lets an eval check one line.
site_fact
| field | type | what it holds |
|---|---|---|
field | enum | which brief field: stage, job, buyer, category, price, plans, trial, proof, integrations, replaces |
value | text | the normalized value, e.g. waitlist or $19.99/mo |
quote | text | the exact sentence it came from, verbatim |
source_url | url | the page the quote is on |
fetched_at | timestamp | when the page was read; re-reads add a new row |
evidence | enum | site_claim for anything read off the site |
status | enum | observed, inferred, founder-confirmed, unknown, conflicting |
model / prompt_version | text | what extracted it, so a bad prompt can be found later |
superseded_by | id | set when a re-read or the founder replaces it; the old row stays |
sample
{
"field": "stage",
"value": "waitlist",
"quote": "Join the waitlist. We're opening to founders soon.",
"source_url": "https://vibedraft.app/",
"fetched_at": "2026-10-16T14:02:11Z",
"evidence": "site_claim",
"status": "observed",
"model": "extractor",
"prompt_version": "site-v3",
"superseded_by": null
}Field names and the prompt version above are illustrative.
field catalog
Every field the site can fill, and where to look
Fourteen fields. The colour says how far the site alone can be trusted for it: teal means the site is the right source, gold means the site is a starting guess, warm means the site can't really answer and the field should become a founder question.
product
Product stage
The first field read. It gates offers and playbooks.
- look at
- waitlist or email form, signup button, checkout, pricing page, "coming soon", a customers page
- signal
- a working checkout beats a pricing page; a pricing page beats a waitlist
- trust
- high for waitlist vs live; low for paying vs not
product
The job it does
One verb phrase that finishes "it…".
- look at
- the hero headline and subhead, the first feature block
- signal
- the verb the site repeats most
- trust
- fine as the site's claim; buyers may describe it differently
product
Category, in the buyer's words
What a buyer would type to find it.
- look at
- title tag, meta description, comparison pages, how reviewers describe it
- signal
- the noun used on 'vs' and 'alternative to' pages
- trust
- medium: sites invent categories buyers don't use
product
What it replaces
Doing it by hand, a spreadsheet, another tool.
- look at
- 'instead of', 'no more', migration and import pages
- signal
- named competitors in import tools
- trust
- a claim until payers say what they used before
product
What they must already have
Hard requirements: tools, platforms, data.
- look at
- integrations page, docs, 'works with' strips, install steps
- signal
- required integrations, not optional ones
- trust
- high: becomes a hard filter
product
First result, and time to it
What a new user gets first, and how fast.
- look at
- onboarding copy, 'in 2 minutes', demo video, docs quickstart
- signal
- the first concrete output named
- trust
- a claim; signup data (tier B) confirms it
price
Price and plans
Public price, plan names, limits.
- look at
- /pricing logged out, checkout pages, FAQ
- signal
- the cheapest paid plan and the plan most people would pick
- trust
- high when public; an unreadable price never demotes a lead
price
Trial or free plan
What a campaign is allowed to offer.
- look at
- pricing page, signup CTA wording
- signal
- 'free trial', 'free forever', 'no card needed'
- trust
- high
price
How buying happens
Self-serve checkout or a sales call.
- look at
- 'book a demo', 'contact sales', checkout buttons
- signal
- no self-serve path means a buying committee
- trust
- high; committees are out of scope
price
Who uses it vs who pays
The role the filter should target.
- look at
- 'for teams', seat pricing, admin features
- signal
- seat pricing hints at a separate buyer
- trust
- low from the site; ask the founder
proof
Social proof
Testimonials, logos, counts, case studies.
- look at
- testimonial blocks, logo walls, 'trusted by N'
- signal
- named people with real profiles beat initials and stock photos
- trust
- a site claim; a testimonial author's own profile can become tier A evidence for observable attributes
proof
Who it says it's for
The buyer the site names.
- look at
- 'for founders', 'built for agencies', use-case pages
- signal
- the most specific audience named anywhere on the site
- trust
- the stated ICP: recorded, never a search query on its own
limits
Where and when it works
Geography, language, compliance, seasons.
- look at
- footer, terms, currency, language switcher
- signal
- single currency or single language
- trust
- partial; confirm with the founder
limits
Channels the founder already has
Their audience, list and communities.
- look at
- social links in the footer, newsletter signup, founder bio
- signal
- a linked X account with real posting history
- trust
- partial; the founder knows the real sizes
failure modes
How it goes wrong, and how to catch it
The wrong front door — The founder pastes a blog post or an app login page, and the extractor reads that. · Catch it: resolve redirects and look for pricing and waitlist links before extracting; store the resolved URL.
Marketing read as evidence — "Loved by 10,000 founders" becomes a fact about who buys. · Catch it: anything about customers from the site stays a site claim; gates keep it out of customer quotes.
Stage misread — A pricing page exists but checkout is closed, so the product is read as live. · Catch it: require a working signup or checkout path for 'live'; otherwise mark the stage conflicting and ask.
JavaScript-only pages — The fetch sees an empty shell and the extractor fills fields from the title tag alone. · Catch it: flag pages with almost no text; render or skip, and mark affected fields unknown.
Stale re-reads — The site changed price, but the brief still shows the old one. · Catch it: re-read on a schedule and on demand; a changed value adds a row and sets superseded_by.
Invented fields — A plausible price or audience the site never states. · Catch it: no quote, no field: an eval checks that every value appears in its quote.
data to capture
Record it so a model can learn from it later
Every decision on this page is training data if it is recorded in the guide's shape from day one.
1 · log the decision · 2 · version whatever decided · 3 · freeze the inputs · 4 · keep the negatives · 5 · log the odds · 6 · every human touch is a label · 7 · one chain of ids · 8 · keep the raw
record
- every site_fact row with its quote, URL, fetched_at, model and prompt version
- pages fetched, their size, and which ones failed to render
- the founder's verdict on each field: kept, corrected (before and after) or rejected
- time the founder took to confirm the block
label
per field: kept, corrected or rejected by the founder
trains
an extractor eval set (every corrected field is a test case), and a per-field accuracy score for each prompt version
test
- knob: the extractor prompt and model
- mode: offline replay on stored pages, scored against founder corrections; no live risk
- win rule: fewer corrected fields per brief, with no rise in 'unknown' fields