Part XII taught the rule this final part enforces: an application begins with an outcome a person wants, not a model feature someone wants to show off. Class 90 turns the whole ByeBuy curriculum — files, models, tools, data, infrastructure, agents, software, media, distribution, monetization, scale — into one narrow, testable plan. That plan starts here, with one real job.

Outcome first, feature second

Most final projects fail at the first sentence. "An AI platform for investors." "An AI assistant for small businesses." "An AI content engine for creators." Each describes a capability, not a change in someone's day. No one wakes up wanting a platform. They want a brief they can forward, a slot filled on the calendar, a garment ready by Thursday, a lesson that answers one question.

Part XII's revisit is blunt: if you cannot name the person and the changed condition, you do not have a project yet. You have a demo looking for a user. AI belongs only where it makes an existing workflow materially better — faster, more reliable, more verifiable, cheaper to repeat. Everything else is decoration.

Learn the vocabulary precisely. You will use it in every artifact through Lesson 90.10:

• User — the person who does the work and feels the outcome.
• Buyer — the person who decides and pays. Sometimes the same as the user, often not.
• Job to be done — the task the user is already trying to complete, in their words.
• Workaround — what they do today: spreadsheet, intern hours, late-night searching, nothing.
• Pain — what the workaround costs: time, errors, missed filings, lost bookings, anxiety.
• Outcome — the observable changed condition after your work succeeds.
• Proof — how a stranger can tell the outcome happened.
• Non-goal — what you deliberately will not do in the first version.

Keep user and buyer separate even when they look identical. The independent analyst uses the brief; the fund manager approves the subscription for its audit trail. The parent books the tutoring slot; the student attends. Confusing the two produces pricing, messaging, and permission errors that surface months later.

The narrowness test

Write one paragraph with three names: the first user, the one job, the changed condition. Then test it:

If yes, the scope is narrow enough to plan. If the paragraph needs "and also," "or anyone who," or "powered by GPT-Whatever," it fails. Narrow it until it feels almost embarrassingly small. Small is what ships, learns, and earns the right to grow.

Two examples, weak versus credible:

• Weak: "An AI platform for investors." Who? Which decision? What changes? What proves it? No buyer could evaluate this, no builder could scope it, no reviewer could test it.
• Credible: "A source-linked research brief that helps an independent analyst compare one public company with its recent filings and peer context, delivered as a one-page brief where every claim links to its source." The user is named. The job is bounded. The proof is inspectable. A human could judge it in five minutes.

Apply the same narrowing to the other running examples:

• ByeBuy Classroom: not "an AI education platform" but "a practical Markdown lesson that helps a self-taught builder complete their first model API call and verify the response."
• Local service launcher: not "AI for small business" but "a booking request flow that helps a homeowner with a broken fitting get a confirmed same-week slot in under two minutes."
• Creator-led niche media: not "an AI content engine" but "a weekly brief that helps 500 working tailors see three verifiable same-week repair techniques with photos and costs."

Each credible version names a person, a moment, and a verifiable after-state. Each weak version names a technology and hopes a person shows up.

Platform versus brief: why the small version wins

The platform instinct says: build the general system first, then find jobs for it. The brief instinct says: solve one job completely, then notice which parts repeat.

The brief wins for four reasons. First, it is reviewable: a human can check sources, prices, dates, and logic. Second, it is sellable: a buyer compares it to three hours of analyst time, not to "the future of AI." Third, it is buildable: one input, one transform, one output, one review step — the system map of Lesson 90.2 stays small. Fourth, it teaches: one job produces one behavior signal, one quality signal, one customer question, one cost signal — the evidence loop of Lesson 90.7 has something to measure.

A platform promises everything and proves nothing. A brief promises one thing and proves it with links, timestamps, and a forwarding test: would the analyst send this to a client without rewriting it?

Exercise: write PROJECT-ONE-PAGER.md

Create FINAL-PROJECT/PROJECT-ONE-PAGER.md. Fill every section. Blank lines are undecided scope — decide or defer explicitly.

# PROJECT-ONE-PAGER — [Project name], [date]

## User
- Who: [name the first user, role + context]
- Moment: [when/where the job arises]

## Buyer
- Who decides/pays: [name + relationship to user]
- What they need to approve it: [budget, proof, guarantee]

## Job to be done
- In the user's words: [one sentence]

## Current workaround
- Today they: [steps they take now]
- Tools used: [spreadsheet, search, intern, nothing]

## Pain
- Costs: [time, errors, missed opportunity, stress — with a number if possible]

## Desired outcome
- After-state: [observable changed condition]
- By when / in what form: [deadline + artifact]

## First use case
- Narrow slice: [one person, one job, one Tuesday moment]
- Narrowness paragraph: [user + job + changed condition, no AI buzzwords]

## Non-goals (v1 will NOT)
- [explicit exclusion 1]
- [explicit exclusion 2]
- [explicit exclusion 3]

## Proof of value
- How we will know it worked: [forwarded brief, booked slot, completed check]
- First check date: [date + method: observation, interview, log]

Finish line: a one-pager another person can understand without an AI buzzword glossary — user, buyer, workaround, outcome, first use case, three non-goals, and one proof.

Verify: hand the narrowness paragraph to an outsider. Ask: who is it for, what changes, and how would you check? If any answer is wrong, rewrite the paragraph, not the listener. Then scan for banned vague words — platform, assistant, engine, powered, smart, seamless — and replace each with a concrete noun and verb.

Common failure mode: smuggling the platform back in through non-goals ("v1 excludes multi-company comparison" while the spec still implies it). Non-goals must shrink the build, not just postpone the brochure. Its mirror is the two-user start: "analysts and advisors and students." Pick one. The second user is Lesson 90.8's problem, after the first job proves real.

Check your understanding

1. Why does distinguishing user from buyer change the proof and pricing of a project? 2. Rewrite "an AI assistant for clinics" into a narrowness paragraph that passes the stranger test. 3. What makes "every claim links to its source" stronger proof than "high-quality AI summary"?

Next

You have one job worth solving. Lesson 90.2 draws the whole system behind it — only the layers you actually need — so dependencies and deferred complexity become visible before you build.