Build Your 90-Day Plan to Scale From First Wins Toward 1,000,000 Organic Visits

Turn your course work into three bets you can actually finish

The path toward one million organic visits is not a 100-page content calendar. It is a repeatable sequence: choose a real customer problem, build a useful and accurate answer, connect it to related decisions, inspect what happened, then make the next evidence-backed improvement. This final workshop turns the files you made across the course into a 90-day plan that has enough focus to run.

You do not need a new site to use it. A beginner can plan the first pages; an existing site owner can plan a repair, refresh, and new cluster. Codex prepares the plan and its packets. A human still approves content, deployments, budgets, outreach, account access, and anything that changes the public web.

Your finished result: a 90-Day Organic Growth Plan with three or fewer active bets, named owners, proof requirements, a capacity-aware calendar, weekly review dates, measurement notes, and a stop or change condition for every bet.

Allow 60-90 minutes. Bring the approved materials that survived review: your Growth Start Card, Traffic Mission, Fact Pack, customer-question map, first-page or existing-page notes, topic map, quality-gate records, weekly reviews, AI answer observations where relevant, and refresh decisions. Bring your actual capacity too: the number of content, technical, and owner-review hours you can provide in a typical week.

Build from saved decisions, not from a brainstorm

Start a file called plan-input.md. It should be a short inventory of proven or reviewable opportunities, not a graveyard of keyword ideas.

plan-input.md
Current position: one approved preparation checklist; an existing monthly
bookkeeping service page; no public proof for claims outside the UK.
Reader mission: help UK freelance designers decide whether organised records
and monthly bookkeeping support fit their situation.
Evidence that survived review: two dated customer notes about remote-service
fit; Fact Pack supports service scope and tax-return exclusion; first checklist
page is live; Refresh Decision says keep URL and add a narrow fit pathway.
Capacity per week: content owner 2 hours; subject owner 30 minutes; developer
2 hours every second week. No budget for paid placement or a new tool.
Open risks: service-area wording needs owner approval; performance comparison
for the newest page is not complete.
Not in scope: city landing pages, paid backlinks, broad tax advice, site redesign.

Notice what is missing: a traffic forecast, fifteen generic topics, a promise to make a tool, and vague "technical SEO." Those are not decisions you can execute. The input establishes the boundary that lets Codex refuse distraction.

Use the three-bet planning prompt

Attach plan-input.md and the source files it names. Then copy this prompt:

Read [plan-input.md] and these approved sources: [Traffic Mission, Fact Pack,
question map, topic map, quality-gate records, weekly reviews, AI observations,
and refresh decisions]. Create 90-day-organic-growth-plan.md.

Include:
1. CURRENT POSITION: facts only, with source files and unknowns.
2. THREE GROWTH BETS MAXIMUM. Each bet needs a customer problem, page or asset,
   approved proof, visitor action, owner, effort, dependency, measure date,
   and explicit continue/stop/change condition.
3. THREE 30-DAY SPRINTS with work small enough for the stated capacity.
4. A weekly review rhythm using one dated evidence folder and one action.
5. MEASUREMENT: organic/search evidence, page outcome, conversion definition,
   and separate AI-answer observations where useful. Do not merge them.
6. RISKS, owner decisions, and work deliberately excluded for 90 days.
7. Links back to the relevant course workshop for each work packet.

Separate facts from forecasts. Do not invent traffic, ranking, revenue,
capacity, source data, or conversion rates. Do not publish, allocate spend,
contact anyone, create accounts, submit URLs, change analytics, or make a
production change.

Read the plan as a capacity test before you approve it

Codex should never fill all three bets just because the prompt permits three. The right number is whatever can be completed and inspected. For Northstar Books, this is a credible first draft:

Bet three can be "verify and wait." That is a real bet when a new page has no completed comparison period. It protects the team from constantly rebuilding the one asset that needs time to be read.

Reject an impossible plan

If the plan asks one person to produce five pages, a migration, a tool, local profiles, outreach, schema changes, and daily reporting in the first month, reject it. Use this repair prompt:

This plan exceeds the stated capacity. Rebuild it around the smallest set of
completed, reviewable bets. Keep a bet only when it has a named owner, approved
proof, one next deliverable, and an inspectable measure date. Move everything
else to EXCLUDED WORK with the evidence required to revisit it.

A smaller plan that reaches its review dates teaches you more than an ambitious calendar that produces unverified drafts.

Lay out the three sprints before you create more work

Each 30-day sprint has a different job: establish a reliable input, release a small approved change, then inspect and decide. Here is a concrete calendar that fits the example capacity.

This is intentionally not "publish every week." Your cadence follows what can be sourced, reviewed, and measured. If a fact is blocked in Sprint 1, shift the page deliverable to evidence collection; do not replace it with a random topic.

Make every bet pass four gates

Before a bet enters the active plan, evaluate it with the same four questions:

The service-fit page fails if nobody can approve its location or eligibility boundary. The answer asset fails if it duplicates the checklist page. The refresh fails if it is cosmetic rather than tied to a reader problem. When a bet fails, put it in the plan's PARKED section with the missing evidence. Do not disguise it as a priority.

Schedule the weekly operating loop inside the plan

Your plan only stays useful if it has a recurring decision moment. Put this line in every active bet: Weekly review: Friday, 10:00; input owner: [name]; approval owner: [name]. Then use the Weekly Codex Growth Loop to create one dated note.

The weekly note answers a different question from the 90-day plan. The plan sets the current bets and stop conditions. The note chooses this week's one action inside those boundaries. If the note proposes a fifth idea, it belongs in PARKED unless it invalidates an active fact or risk.

Use this weekly mini-prompt within the plan:

Read [current 90-day plan], this week's evidence folder, and the active bet
records. Choose one action that advances an active bet or resolves its stated
blocker. Cite the evidence, capacity, owner approval, and measure date. If no
action is justified, prescribe the smallest collection task or wait condition.
Do not add a new bet, publish, spend money, or change a live system.

Measure the system without blending unlike signals

Use a small measurement note for every bet:

Measure: completed Search Console/analytics period for [URL or page group].
Page outcome: [for example, click on discovery-call link, completed checklist,
or qualified inquiry], defined by [owner-approved event or manual record].
AI observation: exact prompt, market/language, date, answer text or screenshot;
record separately from organic sessions.
Review date: [date after an adequate completed period].
Interpretation boundary: compare evidence; do not claim one edit caused a result.

Organic search data, on-page action, customer feedback, and AI-answer observations can all help, but they are not interchangeable. A mention in an AI answer is not an organic session. A rise in impressions is not a qualified inquiry. Keeping them separate gives Codex an honest basis for the next action.

Run the 30-, 60-, and 90-day reviews

At day 30, ask: did every active bet get its required fact, brief, or release packet? At day 60, ask: did approved changes pass the publishing gate and get a saved before-state? At day 90, ask: which bet has evidence to continue, which needs a focused refresh, and which must be parked?

Use this final review prompt:

Read [90-day plan], [weekly review notes], [release notes], and [completed
measurement evidence]. Write 90-day-review.md with: completed work; facts and
unknowns; each bet's continue/stop/change decision; evidence supporting that
decision; lessons to carry forward; and one recommended next 30-day bet. Do
not attribute causation beyond the evidence, revive excluded work without new
proof, or make any external change.

An honest outcome can be: "The service-fit brief is ready, the checklist refresh is released, and performance needs another completed period. Keep the two-page cluster; do not start new location pages." That is how a disciplined site grows instead of constantly changing direction.

Your reusable 90-day plan checklist

• [ ] I used only approved evidence and recorded current unknowns.
• [ ] I have three or fewer active bets, each with a reader problem and proof boundary.
• [ ] Every bet has a named owner, next deliverable, measure date, and stop condition.
• [ ] The first sprint fits real capacity, including review time.
• [ ] Weekly reviews choose one action inside the plan rather than inventing a new strategy.
• [ ] Organic measures, page outcomes, and AI observations remain separate.
• [ ] Any public change will pass the Publishing Gate.

Where to loop next

The plan is not the end of the work; it is the map back to the right workshop. When you need a new demand signal, find 30 real customer questions. When a confirmed page earns a distinct next decision, build a 5-page traffic cluster. When public facts disagree, correct them at the source. When an existing page has evidence but weak clicks, use the refresh workflow.

Keep this loop running: evidence -> one approved packet -> controlled release -> review -> next decision. That is the operating system behind meaningful, compounding organic growth.

Author: Aaron Wolfe, Organic Growth Systems Designer with 15 Years in SEO/GEO at Auspia. Aaron writes about turning first wins into durable organic-growth operating systems.

Use this sequence for the assignment: start with a real input, check the evidence, prepare one reviewable output, then choose the reader next step.