A 90-Day Plan, Worked Through

Learning goal: Apply the tools of documents 01-09 to the example studio all at once, and be able to write your own 90-day plan that triages twelve prototypes and sets hours, experiments, launch dates, revenue scenarios, runway and checkpoints.

This document adds no new theory. It is practice in using the earlier documents' tools in order, in one pass. All numbers are illustrative assumptions; sources for fees and benchmarks are in the relevant documents.

As of: 2026-09-29.

Key Concepts

Starting point (assumption, the example studio from document 01):

The 90-day plan runs in seven steps: (1) triage the 12 (02, 03) (2) choose 2-3 bets (02) (3) allocate hours totaling 160 (01, 08) (4) validation experiments and thresholds (03, 09) (5) launch schedule (08) (6) revenue scenarios and runway (01, 04-07) (7) day 30, 60 and 90 checkpoints (09).

Principles

• Why 90 days: spending 90 days of a 5.1-month runway still leaves about two months to change direction if the plan is wrong. It fits one of document 08's 8-week cycles and part of the next.
• Scoring criteria (1-5 points each, 25 total):
  • D demand signal: evidence by document 03's standards (conversations, waitlist, pre-sales)
  • M money path: is the way to get paid clear and attachable right away (04-07)
  • S closeness to launch: higher when less work remains
  • R reach: is there already a channel to bring the first 100 users (08)
  • F fit: skills, interest, existing assets
• Tie-break rule: on equal scores, pick the one that adds more model diversity to the portfolio (document 02's barbell).
• WIP limit: following document 02's recommended starting point, at most two in building (T1, C2) and two in validation (GM1's store page, P2's fake door). The operating P1 comes on top (02's operating slot).

Applied: The Example Studio

Step 1: Triage

• GM1 and P2 tie at 17. P2 uses the same "sell a tool on the web" model as T1, while GM1 adds a different model, a premium game. By the tie-break rule, GM1 gets 32 hours a month and is validated through a Steam store page, while P2 gets only a 4-hour-a-month fake door validation.
• P1 and the G4 gate: P1 launched on 2026-06-15 (assumption), so G4's 60-day window (2026-08-14) had already passed before D0, but P1 shipped before G4 in 02 (60 days after launch: monthly net revenue of KRW 100,000 or more, or 100 weekly active users) existed, so it had no criteria set in advance. With KRW 0 revenue it already misses G4's revenue bar, but inventing criteria after seeing the result and ruling at once would also be judging after the fact. So at D0 the first date and state are written with the same numbers as G4: "At D90 (2027-01-03), if P1 has fewer than 100 weekly active users and under KRW 100,000 monthly net revenue, archive it and move its 4 maintenance hours to T1 (if T1 was archived at D60: to building P2 when P2 passed G2 at D28; if P2 also missed, to running C2 and preparing next quarter's triage)." Until then it gets only 4 hours of maintenance, and the criterion does not change again (the decision-rule table in 09).
• How P2 is validated: 02 and 03 validate a productivity app candidate with interviews first (G1). P2 passed G1 last quarter when 4 of 5 interviewees said they had faced the problem recently (the basis of its D score of 4, assumption), so this quarter measures G2 with a fake door waitlist page. The method did not change; the gate moved one step forward.
• The 7 archived prototypes (games GM2 and GM3, creative tools T2, T3 and T4, productivity app P3, content site C1) match 02's archive. 1 operating + 2 building + 2 validating + 7 archived = 12.
• Archive is not deletion. The repository stays; only the time allocation goes to zero. It re-enters next quarter's triage.

Steps 2-3: Bets and Hour Allocation

Deviations from 02's default allocation (02's table is the default)

Step 4: Validation Experiments and Thresholds

Step 5: Launch Schedule (D0 = Monday 2026-10-05)

flowchart LR
    A[D0 plan starts] --> B[D7 C2 ad application]
    B --> C[D14 T1 waitlist page]
    C --> D[D21 GM1 store page]
    D --> E{D30 checkpoint}
    E --> F[D42 T1 paid beta]
    F --> G{D60 checkpoint}
    G --> H[D70 T1 full launch]
    H --> I{D90 checkpoint}

Step 6: Revenue Scenarios and Runway (assumed)

Monthly net revenue (after fees) is assumed in units of KRW 10,000, and from month 4 onward the month-3 level is assumed to hold. A one-off cost of KRW 200,000 (Steam Direct $100 ≈ KRW 140,000 + domain and tools KRW 60,000) is included.

• In the base row, month 2's KRW 300,000 minus about KRW 30,000 from C2 leaves about KRW 270,000 for T1, about 7 payments (270,000 ÷ 37,870 = 7.1). 09's rule checks kill first, so with a payment rate (5% assumed) of 3% or more and fewer than 10 payments, T1 goes on hold at D60, with a re-verdict at D90 after the D70 full launch. Month 3's KRW 800,000 gives T1 about KRW 770,000, about 20 payments. The optimistic row (600,000 − 30,000 = KRW 570,000, about 15 payments) is double down at D60 if the payment rate is 10% or more.
• The baseline row is for comparison, so it leaves out the one-off cost. 750 ÷ 350 = 2.14 → 3 + 2.1 = 5.1 months.
• No scenario reaches KRW 3.5M a month (default alive, document 01) within 90 days. The goal of the 90 days is not survival but extending the runway while finding the product to double down on next quarter.
• Document 09's day-60 dashboard (T1 KRW 450,000 + C2 KRW 30,000 = KRW 480,000) sits between base (300,000) and optimistic (600,000).

Step 7: Checkpoints

• If GM1 has 1,500 or more wishlists at D90, decide on joining the February 2027 Next Fest before its registration deadline (2027-01-10) (document 07). If it misses the bar, archive GM1.
• If T1 is judged double down at D60, the monthly allocation for D60-D90 becomes T1 64 → 80, GM1 32 → 24, P2 4 → 0 (the fake door ended at D28), management and reviews 16 → 12. The total stays at 160 hours (09's decision journal).
• At D90, P1 is judged by the rule written in step 1 (fewer than 100 weekly active users and under KRW 100,000 monthly net revenue → archive, its 4 hours go to T1, or by the fallback written in step 1 if T1 was archived at D60).
• Record every verdict in document 09's decision journal.

Bad example:

Decided to move all twelve forward "a little each". After 90 days: zero launches and KRW 7.5M left.

Good example:

Gave time only to two building and two validation slots, kept P1 on maintenance, and wrote the other seven on the archive list with dates. At D60, T1's payment rate passed the bar, so its hours went up.

Going Deeper

When the Plan Is Wrong

• The pessimistic scenario is a default-dead signal. Cutting burn is faster than raising revenue. Reducing monthly net burn with certain income such as contract work or teaching extends the runway again.
• When numbers hover ambiguously near a bar: follow the pre-set rule and "continue", running only the one experiment most likely to move the primary metric before the next gate.
• When a new idea appears: write it on the archive list and let it compete on the same scoring table in next quarter's triage. Do not raise WIP mid-quarter.

Rules for Switching to Contract Work or a Job

Write the studio-wide stop lines in advance too, in 09's "states and dates" form. All numbers are assumptions and taxes are left out (contract income is pre-tax).

Applying R1 to the scenarios in step 6 (KRW 10,000 units, contract rate KRW 50,000 an hour, product net revenue assumed to stay at the month-3 level during contract work):

In the no-revenue and pessimistic rows, T1 has already been archived by the D60 rule, so the remaining 80 hours follow the fallback, by priority: (1) GM1 if it has 1,500 or more wishlists at D90 (it passed 09's gate) → GM1 56 hours + running C2 24 hours = 80 hours (2) otherwise P2 if it passed G2 at D28 → building P2 56 hours + running C2 24 hours = 80 hours (3) otherwise zero bets, and the 80 hours go to running C2 and preparing next quarter's triage.

If the contract rate is lower than assumed (no-revenue scenario, balance KRW 7.5M at D90):

• With a contract whose first payment arrives a month late (common with contract work), waiting for R1 is too late. In the base scenario R1 fires on the first of month 5 (balance 570), and that month's work is paid in month 6, so month 5 ends at 570 − 270 = KRW 3M, below the R2 line (KRW 3.5M). So start looking for contract work on the first of the month when the balance falls below KRW 7M plus next month's net burn (the first of month 4 in the base scenario, 840 < 700 + 270 = 970). Starting work in month 4 brings the first payment in month 5, and the balance goes 840 → 570 → KRW 7M (570 + 400 − 270), never reaching R2. In the no-revenue scenario R1 fires at D90 already, so even with a one-month delay the balance goes 750 → 400 → KRW 4.5M.
• With no contract work and still no revenue, the balance reaches about KRW 3.3M (750 − 36 days × 350 ÷ 30) at D126 (2027-02-08, a Monday review), and R2 fires.
• Contract work halves the product hours. This rule is not giving up on the studio; it rebuilds the safe end of 02's barbell.

Common Misconceptions

• "The scoring table gives the right answer." The table is a tool for recording and comparing judgment. Leave one line of reasoning per score so it can be corrected next quarter.
• "Archiving means throwing away." Archiving is only a decision not to give time. When new signals appear, it returns at the next triage.
• "Plan on the optimistic scenario." Plan on the base scenario and write the response to the pessimistic scenario in advance.
• "Success means earning living costs within 90 days." In this example, success means extending the runway and finding one product to double down on.

Self-Check Questions

1. Score your own prototype list on D, M, S, R and F, and pick the top three by total. How do you break ties?
2. If the main bet gets 40% of a 40-hour week, how many hours is that a month? Allocate the rest so the total is 160 hours.
3. If month-3 net revenue is KRW 500,000 and holds after that, what is the total runway including the KRW 200,000 one-off cost? (Months 1 and 2 net revenue are 0 and KRW 200,000.)
4. If T1 has a 5% payment rate and 12 payments at the D60 checkpoint, what is the verdict under document 09's rules? And with the same rate but 8 payments?
5. Use the runway formula to explain why, in the pessimistic scenario, you cut burn before raising revenue.

References

• Paul Graham - Default Alive or Default Dead? (2015) (accessed 2026-09-29)
• Basecamp - Shape Up (accessed 2026-09-29)
• Behavioral Scientist - Annie Duke, Mental Models to Help You Cut Your Losses (accessed 2026-09-29)
• Steamworks - Steam Direct Fee (accessed 2026-09-29)
• Steamworks - Steam Next Fest: February 2027 (accessed 2026-09-29)