After the ship: watch real use and decide the next move

You arrive from Write your Build Plan and ship with the shipped link, the signed Model Spec, and the Proof Table. A build only you visit proves nothing localhost had not already proved, so what remains is not a build task: get the link to ten strangers, read what they did, and decide the next move.

Get ten strangers: post where your person gathers

The one-pager from Find your build and give the model a job names one real person, and that person already gathers somewhere specific. The worked build's person runs renewal calls, so its link goes where those people compare notes: a revenue-team Slack community, r/sales, a sales newsletter's comment thread. Yours implies different rooms, and the move is the same: you are handing a tool to ten people who have the exact task it does, not announcing a product.

Every community that tolerates this has rules: Hacker News runs a dedicated Show HN format with published guidance, most subreddits pin a self-promotion policy, and nearly all expect participation before you post. Break the norms and the post is gone before a stranger clicks.

Here is our ask:

I built a free page that turns an attendee list, raw notes, and the last call's summary into a one-page brief before a renewal call. If you run calls like this, I want to know where the brief gets your account wrong, not whether the page looks nice.

The message is two sentences, what it does and what you want to know, and the second does the real work: "where is it wrong" invites answers you can act on.

Ten strangers beat a hundred visitors because ten sessions can be read whole, and at this level that whole-session read is your entire measurement system.

Read the logs: your first analytics

The host's log and the provider console's usage view hold everything you need: the log records every request, the usage view every model call with its token counts. Here is one stranger's session in the worked build's host log, three days after the ask:

19:12:04  POST /api/brief  200  9.1s
19:12:58  POST /api/brief  200  8.4s
19:31:47  POST /api/brief  200  11.9s

• The request. One line per call to the route, and the 200 says a brief rendered. The second lands 54 seconds after the first: the stranger read one brief and immediately ran another, which separates using a tool from glancing at one.
• The latency. The trailing figure is the wait: 9.1 and 8.4 seconds sit on the nine seconds the Build Plan promised, and 11.9 is an outlier the next view explains.
• The token count. Tokens live in the usage view, one row per call. The 19:31 row shows about three times the input of the other two: the stranger pasted a twelve-message email thread where the page expects three short texts, and the call cost more, ran slower, and still parsed.

FuelTheFam runs on the same two views: nobody on our team reads a fridge list before the parent sees it, so the logs are where we meet the feature's real life, latency read against the budget that lets a parent log a full day of meals in under three minutes, cost against the fraction of a cent a list should run.

The strangest real inputs become Proof Table rows

Your Proof Table's five inputs share one author, and strangers will not stay inside your imagination. The five strangest inputs across the worked build's first ten sessions:

• the twelve-message email thread pasted whole, which passed, slowly
• notes typed half in Spanish, where the brief came back in English with every Spanish line missing
• the attendee list pasted into all three boxes, which the empty-brief check caught
• a paste carrying a customer's contract clause, which changed nothing in the output and a great deal about how seriously the data-handling line gets reread
• shorthand notes ("upsell?? blocked, legal, SEE THREAD") that produced a confident open-items list from almost nothing

Each became a row, six through ten, with a pass bar written before the rerun. The two failures, the Spanish notes and the shorthand, are worth more than the eight passes, because each names a change you would never have invented at your desk.

After the ship the Proof Table becomes a living regression net: the strangest real inputs join as rows, every change reruns every row, and the table turns into your first eval.

Decide: iterate, hold, or kill

The obvious objection is that ten strangers cannot justify a verdict, and as statistics that is right, just as five photos proved nothing when you chose your model. But the verdict is not a rate; you are reading whether the task exists outside your head, and the deciding signal needs no sample size: whether anyone came back unprompted, days later.

• Iterate when the log shows unprompted returns and the new rows name fixable failures: pick one change from a failing row, make it, rerun all ten rows, re-date the spec.
• Hold when the build does its job for its person, even if that person is only you, and nothing demands a change; the worked build idles under its caps for pennies a month, and a monthly log read keeps the hold honest.
• Kill when nobody returned and the ten sessions left no change worth making. Take the route down; keep the repo, the spec, and the table. This is the Playbook's kill rule applied to a whole build: when more rounds spend attention without converging on anyone's real task, the cheapest move is to end them.

A kill closes the product and keeps every skill that built it: the tier choice, the server-side key, the caps, the ship, and the log reading transfer whole to the next one-pager, and the ten sessions you just read tell you where to aim it.

What you carry out of the Fundamentals

This watching is the manual version of a discipline the next level teaches with rigor: The Practice turns the table into scored evals and the log read into instruments that watch for you, starting where Production signals: evals after the ship picks up. You leave with a live product, a signed Model Spec, a Proof Table with real rows, and the habit of deciding from watched use instead of remembered intentions.

Try it now

The drill spends about an hour across the days the strangers arrive, and the only tokens spent are their requests, pennies at mid-tier rates. You arrive with ship day's artifacts: the shipped link, the signed Model Spec, and the Proof Table. You leave with the Decision Memo, one paragraph on what ten strangers' use actually showed and whether you iterate, hold, or kill, plus five real inputs added as rows six through ten.

No setup: Work from the evidence printed above: read the three log lines and the five new rows as if the worked build were yours, and write its Decision Memo, the verdict they support and the first change you would make. Then draft your two-sentence ask and open the community your one-pager's person inhabits to read its self-promotion rules; reading needs no account.

With your tools: Post the ask in one community whose rules you have read, then have Claude Code group each day's host log and usage rows into sessions, listing requests, tokens, and latency and flagging inputs unlike your original five. At ten strangers, add the five strangest as rows, rerun all ten, write the memo, and commit both beside the spec. Same move in Codex or Cursor: have the sidebar chat summarize the log and usage view into sessions. If your tools are not ready, the Setup Clinic gets you there in one sitting.

Chapter Summary

• A shipped build with no visitors proves nothing new, so the last mile of the Fundamentals is watching real use and deciding from it.
• The link goes where your one-pager's real person already gathers, and each community's self-promotion rules decide how it lands there.
• The ask is two sentences, what it does and what you want to know, and asking where it is wrong produces answers you can act on.
• Ten strangers beat a hundred visitors because ten sessions can be read whole, and read sessions are the measurement system at this level.
• The host log carries the request and the latency, the provider console's usage view carries the token counts, and together they are your analytics until you build analytics.
• Strangers send inputs you would never invent; the five strangest become Proof Table rows six through ten, and the table becomes a living regression net rerun on every change.
• The deciding signal is the unprompted return: iterate on fixable failing rows, hold what serves its person for pennies, kill what nobody revisits.
• A kill closes the product and keeps every skill that built it, ready for the next one-pager.
• Change nothing until all ten sessions are in; then one change, one rerun, one re-dated spec.

The watching habit, done with rigor, is the whole subject of The Practice, and Production signals: evals after the ship picks up exactly where this chapter leaves you.

Sources

• Hacker News, Show HN guidelines (last verified July 2026).
• Reddit self-promotion guidance and subreddit self-promotion policies (last verified July 2026).
• Anthropic and OpenAI usage console documentation (last verified July 2026).
• Vercel runtime logs documentation (last verified July 2026).
• FuelTheFam (fuelthefam.com), our family nutrition app; the fridge-feature operations described in this chapter are live behavior in the product.