What a build-ready plan actually looks like

What the document is, and what it is not

A blueprint is not a spec, and it is not a backlog. A spec describes behaviour in detail and goes stale the first week. A backlog remembers everything and decides nothing. A blueprint sits between them: it records the decisions that everything else depends on, and stops.

It is short on purpose — seven sections, a few pages. Anything longer stops being read, and a plan nobody rereads is a plan nobody follows.

1. Positioning

Three lines, and they have to be able to turn a feature down.

• One line.CoachDesk lets independent coaches run bookings, payments, and client notes from one page — without stitching together five tools.
• Target user.Independent coaches — fitness, career, language — with 5–30 active clients, currently juggling Calendly, Stripe links, a spreadsheet, and WhatsApp.
• The one problem v1 must solve.A coach loses hours every week, and looks unprofessional, switching between disconnected tools for booking, payment, and rescheduling.

Note how narrow the user is. “Coaches” would have admitted every feature any coach has ever wanted. “5–30 active clients, already using four tools” rejects both the beginner with no clients and the agency with staff — and those two rejections are worth more than the sentence itself.

2. MVP boundary

What ships:

• Coach profile with a public booking page
• Session scheduling with real timezone handling
• Payment per session, at the moment of booking
• Reschedule and cancel, driven by one cancellation policy
• Client list with session notes
• Email confirmations and reminders

And the half that does the real work — what is out, with the reason attached to each cut:

Each reason is doing a job. Six months from now, when someone asks why there are no packages, the answer is on the page — and it is a reason, not a preference. That is what stops a cut from being re-argued every month.

3. Core features, by the job they do

Not a list of nouns. Each feature carries a sentence explaining what breaks without it.

Read the right-hand column on its own and the product is still legible. That is the test. If a feature's job column says something like “users expect it,” the feature has not earned its row — the failure behind why more features create less clarity.

4. Pages and key flows

Pages: public booking page, booking confirmation, coach dashboard with today and upcoming, availability settings, client list, client detail with notes, payments and payout settings, sign-in.

Then the flows — written as prose, because prose forces you to name the moment a flow crosses into another system.

Three flows, and every one of them touches email, payment, or a policy. Those crossings are not incidental detail — they are where the next section comes from.

Note how short this section is relative to the work it implies. Eight routes and three flows is the summary; extracting them from the feature list is where the failure screens and empty states turn up, and those are most of the build.

5. Critical dependencies

The decisions that touch everything else, and therefore have to be made before the build order exists rather than during it.

• Timezone storage.Store UTC plus the coach's and the client's timezones from day one. Touches booking, reminders, rescheduling, and calendar files. Retrofitting this later means rewriting the core.
• The cancellation policy as one object.One policy drives the reschedule flow, refunds, and email copy. Hard-coded inside each flow instead, every policy change means touching four features.
• Payment provider and the refund path.Refunds have to map to the policy. Hosted checkout versus an embedded form changes compliance scope and build time.
• Auth model.Clients book without accounts, through email-token links. Deciding later to add client accounts touches booking, note privacy, and every reschedule link already in the wild.

A dependency is any decision more than two features read from. Everything else is a preference.

This section is also where a feature request gets priced honestly. “Let clients book a recurring weekly slot” reads as one checkbox and lands on five systems — availability, payments, the cancellation policy, reminders, and calendar editing. Written down here, it is out of the MVP for a reason anyone can check. That is seeing what breaks before you build, applied to scope rather than code.

6. Build plan, and 7. what is still open

Only now is there enough information to order the work. Ordered so nothing gets built twice:

1. Foundation — auth, coach onboarding, availability model with timezones. The riskiest data model goes first.
2. Booking core — public page, slot selection, confirmation emails. Payments off behind a flag, so booking is testable end to end for free.
3. Money — checkout, the policy object, the refund path.
4. Reschedule and cancel — built on top of the policy object, not before it exists.
5. Client memory — list, detail, session notes. Can run in parallel with stage 4.
6. Polish and launch — reminder emails, empty states, onboarding checklist.

Stages 1 to 3 are sequential because the dependencies are hard, not because they are important. Each stage ships something testable — a stage that ships nothing you can try is not a stage, it is a status update.

Then the last section, the one that keeps the document honest: the decisions not yet made.

• Are free intro sessions part of v1? Touches payments and booking rules.
• Is this a solo tool forever, or will teams exist someday? Affects the auth and data model now, not later.
• Refunds: automatic by policy, or manual approval per case?

Writing these down as open is what stops them being decided by accident, by whoever writes that part of the code first. They are also the first thing to work through once v1 ships, because that is when the evidence they were waiting for finally exists.

How to use this on your own product

Copy the seven headings into an empty document and fill them in order. The order is not cosmetic — each section is what makes the next one answerable, which is the argument in the method itself.

• Write the cuts before the features.If the “out” list is empty or has no reasons, the boundary is not real yet and everything after it will drift.
• Give every feature a job sentence.Any feature you cannot finish that sentence for is a habit borrowed from another product.
• Hunt for the two-reader decisions.Anything more than two features read from belongs in dependencies, before the build order is written.
• Let the plan stay short.A few pages that get reread beat a specification that gets skimmed once.

The point of finishing it is what you can hand over afterwards: a build order that a developer, or an AI coding agent, can work from with the decisions already made — instead of making them for you, quietly, one convenient afternoon at a time.