# Build plan: [product or feature]

From The Field Guide to Shipping Software, brightdot.tech/field-guide/

How to use it: fill this in before you commit to a production build. Prototypes that test an assumption can come first; they're how you answer section 4. Paste it into Claude Code, Codex or Cursor together with your notes. Ask it to fill in what it can and to list the questions it can't answer. Then answer those yourself.

## 1. The first user and their problem
Who they are (one kind of user, not everyone):
The problem, in their words:

## 2. The one job version one must do
The workflow a user can complete from start to finish:

## 3. Not now
Good ideas we're not building yet:
-

## 4. The riskiest assumption
What it is:
How we'll test it, and by when:

## 5. Done means
Acceptance criteria (what must be true before we call it done):
The failures it must handle:
How we'll monitor it:
Who owns it after release (see section 8):

## 6. First release
What reaches users first, and the date:

## 7. Technical calls
Build (what makes us different):
Buy (what every company needs):
Decisions, one paragraph each (what we chose, what we didn't, why, and what would change our mind):

## 8. Team and owners
Who, how many, and which starting point (you have a CTO, you don't have one yet, or you have an asset, not a product):
Who decides scope, priorities and trade-offs:
Who runs it in production:
The named person on the product side who answers "is this what you meant?":

## 9. Budget
What we'll spend to reach the first release:

## 10. Running it
Monitoring (errors, latency, the business number):
On call and runbook:
Backups (when were they last restored?):
Running cost per user, including AI models:

## 11. Outcome and decision
The number we'll check, and the date:
What result means we continue, what means we change direction, and what means we stop: