> ## Documentation Index
> Fetch the complete documentation index at: https://course.pokesignal.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Build Your 90-Day Plan

> Bring the course's decisions into one operating plan with a baseline, ordered work, weekly measures, review dates, and prewritten branches.

Use this page to turn the course's completed decisions into the next 90 days of work. Copy the
definitions, boundaries, and source dates from their owner pages. When an input is missing, record
the dependency that must be resolved. When it does not apply, write *not applicable* and why.

Day 30, 60, and 90 are decision dates. The work between them depends on the business's actual
starting point; the calendar does not promise that validation, profitability, or scale will arrive
on a standard schedule.

## Open the planning window

> **Plan owner:** \_\_\_  **Start date:** \_\_\_  **Day 30:** \_\_\_  **Day 60:** \_\_\_  **Day 90:** \_\_\_
>
> **Chosen role from [Chapter 6.3](/chapters/6-3-going-full-time-or-not):** \_\_\_  **Next scale-review date:** \_\_\_
>
> **Reliable business hours or blocks:** \_\_\_  **Protected life boundary:** \_\_\_
>
> **The question this plan must answer by Day 90:** \_\_\_

## Bring forward the current state

Bring forward the final outputs you will actually use during this planning window. Leave a missing
input visible as a dependency rather than rebuilding its rule here.

Keep each value's original unit, period, definition, and date.

| Baseline record                                                                                                                                          | Current value and period                                                                                                                                                                       |
| -------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Resource window (Chapters [1.3](/chapters/1-3-the-three-ingredients) and [1.4](/chapters/1-4-validate-before-you-build))                                 | Reliable hours/blocks \_\_\_; knowledge boundary \_\_\_; saleable starting stock \_\_\_; acquisition budget \_\_\_                                                                             |
| Inventory thesis ([Chapter 3.2](/chapters/3-2-matching-class-to-capital))                                                                                | Primary/supporting lane \_\_\_; lane cap \_\_\_; cash-conversion window \_\_\_; lane-loss limit \_\_\_                                                                                         |
| Offer and cost (Chapters [2.1](/chapters/2-1-you-make-money-when-you-buy) and [2.2](/chapters/2-2-the-real-cost-stack))                                  | Current offer ceiling/assumptions \_\_\_; modeled order revenue \_\_\_; inventory cost \_\_\_; modeled selling/fulfillment cost \_\_\_; modeled contribution \_\_\_; input dates \_\_\_        |
| Pricing ([Chapter 2.4](/chapters/2-4-selling-is-a-math-problem))                                                                                         | Price floor \_\_\_; target \_\_\_; review and markdown rule \_\_\_                                                                                                                             |
| Cash (Chapters [5.1](/chapters/5-1-business-money-hygiene) and [5.2](/chapters/5-2-bankroll-discipline))                                                 | Latest close \_\_\_; cleared cash \_\_\_; commitments/protected/deployable cash \_\_\_; pending payouts \_\_\_                                                                                 |
| Inventory movement ([Chapter 2.3](/chapters/2-3-cashflow-is-oxygen))                                                                                     | Sales/contribution period \_\_\_; turns period/result \_\_\_; item-age rule/result \_\_\_                                                                                                      |
| Operations (Chapters [4.1](/chapters/4-1-sourcing-the-ladder) through [4.4](/chapters/4-4-fulfillment-and-the-customer-promise))                         | Sourcing targets/acceptance boundary \_\_\_; selected venue/test result \_\_\_; intake/sale-ready queue \_\_\_; oldest sale-readiness age \_\_\_; fulfillment method/capacity/incidents \_\_\_ |
| Direction (Chapters [5.3](/chapters/5-3-the-risk-map) and [6.1](/chapters/6-1-systems-before-scale) through [6.3](/chapters/6-3-going-full-time-or-not)) | Measured constraint/response \_\_\_; material risk/control/trigger \_\_\_; demand result \_\_\_; chosen role/blockers \_\_\_                                                                   |

A stale market, fee, carrier, platform, tax, benefit, or similar input returns to its owner record
for replacement. Carry the updated value and source date here rather than creating a second source
record.

## Choose the active work

Schedule the unresolved decision that matters now and any dependency it genuinely requires. A
business still testing its basic offer uses the validation owner first. A mature operation may be
testing sourcing, venue, demand, or a diagnosed capacity constraint. Park work whose question,
budget, or operating capacity is not yet clear.

Complete one record for each active experiment or decision:

> **Owner and question:** \_\_\_  **Baseline:** \_\_\_  **One change being tested:** \_\_\_
>
> **Cash budget:** \_\_\_  **Time budget:** \_\_\_  **Capacity dependency:** \_\_\_
>
> **Outcome measure:** \_\_\_  **Validity rule:** \_\_\_  **Boundary that cannot be crossed:** \_\_\_
>
> **Prewritten result branches:** Pause/stop if \_\_\_; repair/extend if \_\_\_; continue if \_\_\_; change
> \_\_\_ if \_\_\_.
>
> **Review owner:** \_\_\_  **Review date:** \_\_\_

## Put the work in dependency order

The rows below are calendar slots, not prescribed phases. Add or remove rows to fit the active work.

| Start–end | Action or experiment | Must be true first | Owner and finished-when signal |
| --------- | -------------------- | ------------------ | ------------------------------ |
| \_\_\_    | \_\_\_               | \_\_\_             | \_\_\_                         |
| \_\_\_    | \_\_\_               | \_\_\_             | \_\_\_                         |
| \_\_\_    | \_\_\_               | \_\_\_             | \_\_\_                         |
| \_\_\_    | \_\_\_               | \_\_\_             | \_\_\_                         |

## Set the operating rhythm

| Cadence                     | Work and record                                                                | Boundary response                                                                           |
| --------------------------- | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------- |
| Inventory blocks: \_\_\_    | Receive, decide, make sale-ready/findable; record queue and sale-readiness age | Apply the existing pause/recovery rule; open a bottleneck review if the same queue persists |
| Fulfillment windows: \_\_\_ | Perform the chosen handoff; maintain incident and remedy records               | Use the written response deadline and authorized remedy                                     |
| Experiment blocks: \_\_\_   | Run only the planned change; capture outcome and validity evidence             | Apply its budget, boundary, and stop rule                                                   |
| Weekly review: \_\_\_       | Update the scorecard; make one recorded decision                               | Assign the next action, owner, and date                                                     |
| Monthly close: \_\_\_       | Capture, reconcile, resolve differences, and lock/export the period            | Hold decisions that require an unresolved record                                            |
| Trigger review: \_\_\_      | Apply the capital policy and inspect material risk triggers                    | Stop adding to the triggered risk and follow its named response                             |

## Keep a small decision scorecard

Use only measures tied to the work and branches in this plan.

| Measure and owner | Current value / period | Existing boundary or target | Decision if crossed |
| ----------------- | ---------------------: | --------------------------: | ------------------- |
| \_\_\_            |                 \_\_\_ |                      \_\_\_ | \_\_\_              |
| \_\_\_            |                 \_\_\_ |                      \_\_\_ | \_\_\_              |
| \_\_\_            |                 \_\_\_ |                      \_\_\_ | \_\_\_              |
| \_\_\_            |                 \_\_\_ |                      \_\_\_ | \_\_\_              |

## Commit the branch order

Apply these rules in order at every review:

1. A hard boundary breach or unresolved required record invokes **pause/stop**, even when the test
   is incomplete.
2. If no hard boundary was crossed but the test was invalid or incomplete, use **repair/extend**.
3. Only a valid test that stayed within its boundaries can reach **continue** or **change one
   variable**, according to the result written before launch.

> **Pause/stop:** \_\_\_ crosses \_\_\_, a required record remains unresolved, or \_\_\_ occurs. Next action:
> \_\_\_; owner/date: \_\_\_.
>
> **Repair/extend:** The validity failure is \_\_\_. Repair: \_\_\_. New budget: \_\_\_. New review date: \_\_\_.
>
> **Continue:** The valid result remains within \_\_\_ and produces \_\_\_. Next action/owner/date: \_\_\_.
>
> **Change one variable:** The valid result shows \_\_\_. Change \_\_\_; hold \_\_\_ constant; owner/date:
> \_\_\_.

## Record the three decisions

| Review point and date | Evidence and validity | Boundary or assumption that changed | Decision, next action, owner, and date |
| --------------------- | --------------------- | ----------------------------------- | -------------------------------------- |
| Day 30: \_\_\_        | \_\_\_                | \_\_\_                              | \_\_\_                                 |
| Day 60: \_\_\_        | \_\_\_                | \_\_\_                              | \_\_\_                                 |
| Day 90: \_\_\_        | \_\_\_                | \_\_\_                              | \_\_\_                                 |

The plan is complete when every active action appears in the schedule with an owner, budget or
boundary, measure, branch, and date—and every missing dependency is visible. The first scheduled
action is \_\_\_, owned by \_\_\_, on \_\_\_.