You can now build faster than you can think. That is the actual risk profile of everything you learned in Parts 0 through 3: an agent will scaffold, migrate, and deploy a wrong idea with exactly the same cheerful competence as a right one. The expensive failure in agentic engineering is no longer the six months of hand-coding a product nobody wants; it is the six days of dispatches that produce a polished, tested, deployed product nobody wants, plus the three months you spend not admitting it. Part 4 builds a real SaaS end to end, and it starts where the money starts: deciding whether to build at all.
The filter comes before the spec
Lesson 3.1 gave you three spec altitudes: product spec, technical spec, dispatch. This lesson is about what sits above all three, the decision that produces the product spec or kills the project. Four questions, asked in order, each one a kill gate:
Who pays? A person with a name, a job title, and a budget. Not "small businesses". Not "developers". If you cannot picture the specific human who enters a credit card, and roughly how many of them exist, stop here. "Users" who do not pay are a cost center you are volunteering to run.
What pain? Something they already spend money or hours on, badly. The test is present tense: what are they doing about this problem today? If the answer is "nothing", the pain is probably not real enough to bill for. The best answer is an ugly workaround: a shared spreadsheet, a weekly copy-paste ritual, a tool they pay for and hate.
Why now? What changed that makes this buildable or buyable today when it was not two years ago? A new platform capability, a regulation, a cost curve, a behavior shift. Products without a why-now can still work, but you should know you are betting on distribution muscle instead of timing.
Why you? Your unfair input: domain access, an audience, proprietary knowledge of the workflow, or simply the fact that you are the customer. Agentic tooling collapsed the build moat; everyone can build this now. What they cannot copy is your route to the first fifty customers.
The order matters because each question is cheaper than the next to answer honestly, and a kill at question one costs you ten minutes. The most common self-deception is answering question two with a pain you have imagined for a customer you have never met. The filter is not a form to fill in optimistically. It is a machine for killing your own idea before the market does it slower and more expensively.
Validation without building
You have three tools that cost days, not months, and none of them require code:
Conversations. Five to ten people who match the who-pays profile. You are not pitching; you are asking what they do today about the pain, what it costs them, and what they have already tried. Listen for money and hours. "That sounds cool" is a kill signal wearing a compliment; "can I have it next week, we currently pay a VA to do this" is validation.
The landing test. One page stating the promise and the price, with a real signup or waitlist form, put in front of the audience you claim to have. This tests the why-you question as much as demand: if you cannot get 200 relevant humans to see a landing page, you have learned something important about your distribution before it was load-bearing.
The concierge version. Deliver the outcome manually to two or three customers before automating anything. A shared folder, an email thread, you doing the work by hand behind the curtain. This is the highest-signal option because someone pays real money, and every manual step you perform becomes a line in the product spec later. You are writing the spec by living it.
Agents change the economics of exactly none of this, which is the point. The temptation, now that a working prototype is a weekend away, is to skip validation because building became cheap. But building was never the expensive part; the expensive part is the months of attention a launched product demands. Validate like code is still expensive, because your time still is.
Drawing the v1 line
The v1 line is the smallest product someone would actually pay for, and "actually pay" is the discipline. Not the smallest demo, not the smallest impressive thing: the smallest billable thing. Everything on the v1 list must trace to the pain from question two. Everything else goes on an explicit out list, written down, so that scope creep during the build (yours or the agent's) has a named boundary to violate. You already know this move: it is OUT OF SCOPE from the 3.1 dispatch template, applied at product altitude.
The filter, worked: Briefcase
Here is the filter run for real on the product this track builds. Briefcase is a client portal for small agencies: the agency shares deliverables, the client comments and approves, everyone stops spelunking through email.
Who pays? The owner or ops lead of a 2 to 15 person agency: design studios, dev shops, marketing agencies. They bill clients monthly, they run 3 to 20 client projects at a time, and they already pay for six or seven SaaS tools. A $49 per month line item is a rounding error against one hour of recovered billable time.
What pain? Deliverable chaos. Final files live in email attachments, Drive links, and Slack threads. Approval is a reply that says "looks good" three weeks before the client disputes the invoice because they never approved v3. The present-tense workaround is real and ugly: agencies bodge this with Drive folders plus a "STATUS" spreadsheet plus memory. The pain has a dollar shape: disputed invoices and unbillable admin hours.
Why now? The build economics you are living in. A portal like this was a $150k agency-tool startup in 2019; it is now buildable and operable by one person, which means it can be priced for small agencies that the 2019 version had to ignore. The why-now is that the margin structure changed, not the pain.
Why you? For this course: the reader has, or can borrow, direct access to agency workflows, and the product is deliberately domain-neutral so the pattern transfers to whatever vertical you actually know. In your own filter run this answer must be yours, not mine.
The filter passes, with an honest note: who-pays is the weakest answer of the four, because agency owners are heavily marketed to and slow to adopt. That note goes in the brief instead of being smoothed over. A brief that records its own weakest point is worth double, because it tells you what to watch in the first ten customer conversations.
The product brief
The brief is one page. It is the top of the spec chain from 3.1: the technical spec in 4.3 must trace to it, and every dispatch in 4.4 through 4.10 traces to that. Here is Briefcase's, in full. This exact document is what 4.2's design session takes as input.
# Product brief: Briefcase
## One-liner
A client portal for small agencies: share deliverables, collect
comments, get approvals that hold up when the invoice is disputed.
## Who pays
Owner / ops lead of a 2-15 person agency (design, dev, marketing).
Runs 3-20 client projects. Already buys 6-7 SaaS tools.
Price: $49/month flat per agency. 14-day free trial, card required.
Weakest filter answer: this buyer is over-marketed-to and slow to
adopt. Watch conversion from trial closely.
## What pain
Deliverables scattered across email, Drive, and Slack. No record of
what the client approved and when. Costs: disputed invoices,
unbillable admin hours, "which version is final" archaeology.
Current workaround: Drive folders + status spreadsheet + memory.
## Why now
One person can now build and operate this. The price point that
small agencies can pay only works at solo-operator margins.
## v1 IN (the smallest billable thing)
- Agency workspace (org) with roles: owner, admin, member, client
- Projects; clients see only projects they are invited to
- Deliverables: file upload, status (draft, in_review, approved,
changes_requested)
- Comments on deliverables
- Approvals with an audit trail (who, what, when) - this is the
invoice-dispute killer and the core of the product
- Daily email digest of activity (comments, approvals)
- Stripe subscription: one plan, $49/month, 14-day trial
## v1 OUT (explicitly)
- White-label / custom domains
- SSO, granular per-file permissions
- Real-time anything (presence, live cursors)
- Public share links
- Annual billing, seats, usage pricing
- Mobile apps
- Search across deliverables (elective A8 adds this with RAG)
## Kill criteria
If 10 agency conversations do not surface the approval-audit pain
unprompted in at least 4, the core bet is wrong: stop and re-filter.Notice what the brief does not contain: no architecture, no stack, no data model. Those are 4.2's and 4.3's jobs. A brief that names Postgres has skipped an altitude, and skipped altitudes are where unexamined decisions hide.
When to walk away
Walking away is a positive outcome of this lesson, not a failure state. Kill signals worth trusting: nobody describes the pain in present tense without your prompting; the only enthusiastic voices are people who would not pay; the v1 line keeps growing every time you imagine demoing it (a sign the small version is not actually valuable); or the why-you answer is "I will figure out distribution later". A documented kill, one page stating what you tested and why it failed, is a reusable asset. Founders who kill cheap get more attempts, and attempts are the actual unit of progress.
Where it breaks
The filter has failure modes of its own. The first is running it as theater: asking the four questions after you have already decided to build, and grading your own answers generously. The countermeasure is the same one 3.2 gave you for code: pre-commit the pass criteria. Briefcase's kill criterion (4 of 10 conversations surface the pain unprompted) was written before any conversations happened, for exactly the reason your verification gates are written before the code exists.
The second is validating the wrong thing. A waitlist full of other builders validates that builders like product ideas, not that agencies buy portals. Signal only counts from people who match who-pays.
The third is the concierge trap: the manual version works, customers are happy, and you keep doing it manually for a year because building feels like a distraction from serving them. Set a threshold in advance: at N paying concierge customers, the build starts.
Lablab-4-1Filter one of your own ideas
Goal: Run the four-question filter on a real idea of yours and produce one of the two artifacts: a one-page brief, or a documented kill.
Prereqs: one product or tool idea you have been carrying around. If you truly have none, use: a deposit-and-contract tracker for freelance creatives.
- Create the capstone-adjacent workspace for this track's paper artifacts:
mkdir -p briefcase-notes && cd briefcase-notes. Your own idea's artifacts live here too. - Write the four filter answers in
filter.md, one paragraph each, in order: who pays (a person, a count, a price), what pain (present tense: what do they do today), why now, why you. Stop at the first question you cannot answer concretely and mark it KILLED with one sentence on what evidence would revive it. - If all four pass, draft the v1 line: two lists, IN and OUT, where every IN item traces to the pain and OUT contains at least five things you genuinely want to build. An OUT list with nothing painful on it means you have not drawn a line, you have written an inventory.
- Write the brief in
brief.mdusing the Briefcase brief above as the shape: one-liner, who pays, what pain, why now, v1 IN, v1 OUT, kill criteria. Include the weakest-answer note; there is always one. - Pressure-test it with an agent, as a skeptic not an implementer: paste the brief into a fresh Claude Code session with the prompt below.
You are reviewing a product brief as a skeptical investor, not as a builder. Do not suggest features. Do not improve the idea.
For each section: state the strongest reason it might be wrong, and what cheap evidence (under one week, under $100) would settle it. Then answer: which single v1 IN item, if cut, would most customers not notice? Which OUT item will customers demand in month one?
End with a one-line verdict: BUILD, TEST MORE (name the one test), or KILL (name the failed question).
[paste brief.md]
- Update the brief with anything the pressure-test genuinely changed, and commit the folder with git. The brief is now the upstream spec for everything you build for your own product later.
Verify
filter.mdexists with all four questions answered in the present tense, or a KILLED marker at the first failed question with a revival condition.- If you proceeded:
brief.mdhas all seven sections, the OUT list has 5 or more items, and the kill criteria are measurable (a number and a source, not "if it seems weak"). - The pressure-test verdict and your one-line response to it are recorded at the bottom of
brief.md. Disagreeing with the verdict is fine; not recording it is not.
>Troubleshooting
- Every idea passes your filter: you are grading your own homework generously, the 1.5 pattern in product clothing. Re-run question two with the standard that the pain must be something the buyer already spends money or hours on today, and name the evidence.
- The agent's pressure-test just flattered the brief: your prompt let it. The skeptic framing above works because it forbids improvement and demands a verdict from a closed list. If it still waffles, add: assume this idea fails in 12 months and tell me the most likely written post-mortem.
- You cannot list five real OUT items: your v1 line is actually a v3 line. Cut IN items until OUT hurts.
Knowledge check
Knowledge check
Sources
- Best practices for Claude Code (spec-first working style and pre-committed verification criteria, applied here at product altitude; the dispatch pattern this brief feeds is 3.1's): https://code.claude.com/docs/en/best-practices (fetched July 2026)
- Briefcase itself is this course's reference product; its brief, numbers, and kill criteria are authored here as the worked example, not sourced from a live company.