Find your build and give the model a job

You arrive with the map of a running product, ending with the monitoring that pages you when it breaks. This part puts a model inside that map, on two builds at once: yours, picked here and carried through every drill to shipping, and ours, FuelTheFam, our live family nutrition app, dissected before each move you make.

Filter your idea list down to one build

The scene above produces this part's worked example: a page where you paste the attendee list, your raw notes, and the last call's summary, and get back a brief covering what was promised, what is still open, and what you want from the call. Before that idea earns four weeks of your evenings, it passes the same filter as everything else on your list.

One real person you can name. The build serves a person whose calendar you could check, not a market. Here that person is you; "better invoicing for freelancers" fails because no specific freelancer has asked you for anything.

One real task they already do. The task exists today, and its workaround has a cost you can count. Meeting prep passes with numbers attached: 25 minutes of assembly across four tools, done badly in four when the calendar compresses them. An idea that needs its user to build a new habit fails, because a build this small can only serve demand that already exists.

Small enough to finish in four weeks. You can say what done looks like a month out. "Replace my CRM" fails here, not as an ambition but as a first build, because no four-week version survives its own scope; the meeting-prep page passes with the done line in its one-pager below.

An idea becomes a build when it names one real person, one task they already do, and what done looks like four weeks out.

Give the model a job

With the build chosen, the next decision is the model's job inside it, and the fastest way to see the options is to look at a model already placed in a product. In FuelTheFam, a parent photographs the open fridge, the app sends the photo to our server, the server attaches the API key and hands it to a multimodal model, and a shopping list comes back while the parent waits. The prompt confines the model to items visible in the photo, a list costs a fraction of a cent at mid-tier rates, and nobody on our team reads one before the user sees it.

That is one of four jobs a model can hold in a product, sorted by who it works for, you or your user, and when it runs, while you build or while people use it.

• It writes the code while you build. The output is reviewed and ships as ordinary code; no user ever touches the model. Nearly every build in this course says yes here.
• It produces content for the user at runtime. The user acts, your product calls a model, and the result renders while they watch; the fridge feature lives here.
• It runs behind the scenes. The model runs as a backend step on a trigger, with nobody watching. Granola holds this job end to end: you type rough bullets while it captures the meeting audio, at meeting end the transcript and your bullets are handed to a model, and finished notes are waiting before your next call. The bill runs per meeting, and a wrong detail sits in stored notes until you read it.
• It is the product. Strip the model out and nothing is left to sell, which is ChatGPT's seat. A build here needs a sharp answer for what it adds, because your user can reach the same model directly.

The job decides the bill before any prompt exists (a subscription that stops when you stop building, a meter on every use, or a schedule you set) and where a wrong answer lands: on your machine under review, live on a person's screen, or in storage where a check can catch it.

The obvious objection is that at a fraction of a cent per call this deliberation is overkill: put the model everywhere and keep what sticks. But the meter is the smallest consequence. The fridge list reaches its user unreviewed, so its real cost is a wrong answer, and meal logging raises those stakes: a dinner-plate photo comes back as a nutrition estimate, and a confidently wrong number tells a parent their underfed kid is eating fine, so outputs like that are guarded before they appear. The same product can be cheap per call and expensive per failure, and the placement tells you which of those numbers matters.

The model's job decides what each use costs and where a wrong answer lands, before a single prompt is written.

Where the model does not belong

Placing the model well includes keeping it out. Code computes totals, conversions, and date arithmetic exactly and for free, while a model produces them approximately and for money; an order status or a balance has one right value where a model offers plausible text. FuelTheFam has one refusal built in: an unreadable fridge photo gets a retake request instead of a generated list, because a made-up list reads exactly like a real one. The cheapest test is removal: if nothing degrades with the model taken out, the model was decoration. The Playbook's when not to use AI checklist goes deeper.

The one-pager, filled in

Here is the chapter applied to the worked example, in the form you are about to produce:

The build in one sentence: a page where I paste the attendee list, my raw notes, and the last call's summary, and get back a one-page brief covering what was promised, what is still open, and what I want from this call.

The one real person: me, before the six renewal calls on this quarter's calendar, replacing 25 minutes of assembly across four tools.

Done in four weeks: pasted text in, one page out, no integrations, used before three real calls and better than the tab-hopping each time.

The model's job: one runtime job, producing the brief while I wait. Everything else on the page is ordinary code.

Every chapter ahead operates on these lines, and the plan you sign when you build, plan, and ship starts from the top sentence.

Try it now

The drill takes twenty minutes and spends nothing. Nothing arrives from an earlier chapter, since this drill opens the part; what leaves is your one-pager v1, which every later drill runs against.

No setup: Paper or a notes app is enough. Run the filter on each candidate idea: one real person, one task with a cost you can count in minutes, a done you can describe four weeks out. Take the survivor, the smaller one if two survive, and write your one-pager from our filled example: the build in one sentence, the one real person, done in four weeks, and the model's one job. If none survives, spend a week counting the minutes your workarounds cost, then rerun the filter.

With your tools: Open Claude Code, paste your one-pager, and set one boundary: "Do not write any code yet." Ask it to attack the last line: which of the four jobs is this, what does a wrong output look like in front of my person, and what would the smallest four-week version drop? Same move in Codex or Cursor: paste the one-pager into the chat with the no-code boundary. If nothing is installed yet, the Setup Clinic gets you running.

Chapter Summary

• You leave this chapter with one build chosen and its one-pager v1 written: the build in one sentence, the one real person, done in four weeks, and the model's job.
• The filter has three checks: a real person you can name, a task they already do with a workaround you can count in minutes, and a version of done that fits in four weeks.
• If two ideas survive the filter, build the smaller one, because it starts teaching you sooner.
• A model can hold four jobs in a product: writing the code while you build, producing content for the user live, running behind the scenes on a trigger, or being the product itself.
• The job decides the bill (a subscription while you build, metered per use, or scheduled) and where a wrong answer lands (your machine, the user's screen, or storage).
• FuelTheFam's fridge feature holds the live runtime job: photo in, list out, unreviewed, a fraction of a cent per list, with a prompt that confines the model to items visible in the photo.
• Keep the model out of exact math, exact lookups, and any answer where a confident wrong number costs too much; when the input cannot support a real answer, ask for better input instead of generating one.
• The removal test: if taking the model out degrades nothing, the model was decoration.
• Give the model one job to start, and let the build earn a second.

Next, what this component actually is and is not: The model is a part, not a coder.

Sources

• Granola product documentation (last verified July 2026).
• OpenAI ChatGPT product overview (last verified July 2026).
• FuelTheFam (fuelthefam.com), our family nutrition app; the fridge and meal-logging behavior dissected in this chapter is live in the product.