Write your Build Plan and ship

That gap is the last one. You arrive from Run the pre-flight with the checklist rows green and a Model Spec one signature short of complete, so nothing today is a build task: the plan gets filled, the spec gets signed, and the build moves to an address that means anyone.

The Build Plan, filled

The plan is one page, and on ship day every field holds a decision you already made and tested. Here is the worked build's page, complete.

Build Plan: the meeting-prep one-pager

What I am building. A page where I paste the attendee list, my raw notes, and the last call's summary, and get back one brief: what was promised, what is still open, what I want from this call.

Who it is for. Me, before the six renewal calls on this quarter's calendar, replacing 25 minutes of assembly across four tools.

The user's journey. Paste the three texts, wait about nine seconds, skim the brief, walk into the call.

The stack. One Next.js project: the page, plus one API route that holds the key server-side and makes the model call. No database, because nothing is stored. A serverless free tier, no login while the only user is me, a rate limit on the route anyway, host logs as monitoring.

Where AI fits. Yes to writing code while I build, and one runtime yes: the model produces each brief from the pasted text; every other role is no. The Model Spec below is the detail behind the runtime yes.

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

Nothing on that page was invented today: the top line is the one-pager v1 that Find your build and give the model a job produced, and the done-when line has been the finish line since before any code existed. A field of yours that refuses to fill is pointing at the one decision still open.

On ship day the Build Plan is a record, not a proposal: every field holds a decision you already made, and the done-when line is the written definition of ready.

The Model Spec, assembled and signed

The plan's runtime yes is one line, and the Model Spec is everything that line means. You have been filling it since Choose the model you ship: the model field when the Proof Table's five real inputs picked your tier, the prompt, output, context, and lever fields as the drills left their artifacts, the fallback when the pre-flight set the caps. Assembled, it fits on one screen.

Here is the worked build's spec:

Model Spec: the brief generator. Signed 2026-07-03.

The job. Produce one meeting brief from three pasted texts, live, while the user watches.

The model. The mid-tier model that matched the flagship on all five Proof Table inputs at a fraction of the rate; the name sits in one config value, so a swap is a one-line diff.

The prompt. prompts/brief.txt, versioned in the repo: the role names the reader and the moment, the rules forbid any commitment not present in the pasted text, one worked example locks the format.

The output. JSON against a schema of three lists, promised, open, and asks, with value checks after the parse; an empty brief asks for more input instead of rendering blank.

The context. Stuffed: everything the brief needs arrives in the paste itself. No retrieval, no store to keep current.

The lever. Instructions plus per-call context, zero tools wired; the calendar-pull tool stays on paper until real use demands it.

The fallback. A hard monthly cap at the provider, a daily cap on the route, and on a timeout or a failed check the page says so and keeps the pasted text.

The same page holds FuelTheFam's fridge feature: photo in, shopping list out, unreviewed; the one-field items schema with its empty-list check; and the fallback we quote most, an unreadable photo gets a retake request, never a generated guess. When a list goes wrong in front of a parent, the spec says which line to reopen; that is its job from today on.

The signature is the only new ink. Dating the page marks these lines as the feature you chose, so that six weeks from now, when the prompt holds three rules nobody re-dated, the drift shows on paper rather than in your memory.

A signed Model Spec makes the feature something you chose rather than something that accreted, and the date turns every later change into a visible decision instead of quiet drift.

The ship, from deploy command to first real request

The obvious objection arrives right about now: it is not ready. Ready has a written definition, and you wrote it. The done-when line names what the build must do, and it already does that on your machine, where the Proof Table's five inputs came from. The pre-flight names what it must never do, and every row came back green. Whatever remains after those lists is polish, and polish sharpens faster against real use than against your imagination.

The mechanics were settled in Hosting, renting a computer on the internet: a deploy copies your saved code onto the rented computer, one command on a serverless host. Here is ours:

$ vercel --prod
Uploading  [2.1 MB]
Building...
Production: https://meeting-prep.vercel.app  [41s]

Open that URL on your phone: your phone is not your laptop, so whatever answers cannot be localhost. Three pastes go in, the brief renders in nine seconds off a computer you will never see, and the host's log shows the request:

14:36:05  POST /api/brief  200  9.2s

Then you send the link that failed in the opening scene, and a quarter hour later the log prints a second line, same route, from an IP address that is not yours: a request you did not make, answered by the build, metered under the caps you set, held back by the rate limit you already turned green.

The ship itself is small and mechanical, one command that moves the build from an address meaning you to an address meaning anyone, and everything that made it safe happened before the command ran.

Try it now

The drill takes about thirty minutes. The no-setup path spends nothing, and the tooled path fits inside a serverless free tier, with the test request costing a fraction of a cent. You arrive with a pre-flighted build and a nearly complete Model Spec, the artifacts Run the pre-flight left you; you leave with the shipped link, the signed Model Spec, and the filled Build Plan.

No setup: Open the Build Plan tool and fill every field from decisions already made, two minutes a field; it saves on your device and exports as a PDF or Markdown. Then download the Model Spec starter, fill its fields for your feature, and sign and date the bottom. Your plan and spec leave complete on paper, and the deploy waits for the day your tools are ready.

With your tools: Ask Claude Code to deploy the project to the host your plan's stack line names, open the URL on a phone, and run one real input. Find your request in the host's log, then commit the signed spec and the filled plan into the repo beside the prompt file. Same move in Codex or Cursor: ask the sidebar chat for the deploy and read the request in the host's dashboard. If your tools are not set up yet, the Setup Clinic gets you there in one sitting.

Chapter Summary

• localhost names whichever machine opens it, so a build living there answers only you; shipping moves it to an address that answers anyone.
• On ship day the Build Plan is a record, not a proposal: every field holds a decision already made, and a field that refuses to fill points at the one still open.
• The done-when line in the plan is the written definition of ready, so "it is not ready" has to name a line item rather than a feeling.
• The Model Spec assembles the decisions behind the plan's runtime yes onto one signed, dated page: the job, the model, the prompt, the output, the context, the lever, and the fallback.
• The signature carries a rule: any change to a spec line reruns the five Proof Table inputs before it deploys, then re-dates the page, so drift stays visible.
• FuelTheFam's fridge feature fills the same page, and its most-quoted line is the fallback: an unreadable photo gets a retake request, never a generated guess.
• The deploy is one command on a serverless host; verify it by loading the URL on a machine that is not yours and finding the request in the host's log.
• The ship moment is the first logged request you did not make, answered under the caps and rate limit the pre-flight turned green.
• You leave the Fundamentals holding the shipped link, the signed Model Spec, and the filled Build Plan; After the ship: watch real use and decide the next move picks up at the log you just opened.

Sources

• Vercel deployment documentation (last verified July 2026).
• FuelTheFam (fuelthefam.com), our family nutrition app; the fridge feature's Model Spec lines dissected in this chapter describe live behavior in the product.