Early Access Without the Death Spiral: Roadmaps, Patch Cadence and Exit Criteria

A two-person team ships into Early Access with a roadmap image on their store page: four columns, four quarters, nineteen features, and the words "and much more!" Six weeks later the forum thread is titled "Where is the co-op you promised for Q1?" — and the honest answer is that co-op was a Tuesday-afternoon idea that got drawn into a box because the column looked thin.

That roadmap did not fail because the team was lazy. It failed because it was built as marketing art instead of as a production document. Early Access is a schedule you have to keep in public for a year or more, and the plan that holds up is the boring one: a fixed 1.0 line, a cadence you can hit on a bad week, and a feedback funnel that ends in a prioritised list instead of a pile of screenshots.

What Early Access actually buys you

Be specific about why you are doing it, because the answer changes the plan.

• Validation of the core loop. You think the game is fun. A few thousand strangers will tell you whether it is fun past hour three — something no friends-and-family playtest reveals.
• Balance data at a scale you cannot simulate. Economy curves, run lengths and difficulty spikes only resolve against thousands of sessions.
• Revenue during development. Real, but front-loaded: the launch week is usually the biggest sales week until 1.0, so treat EA launch as a real launch, not a soft one.
• An audience that compounds. Players who see a steady patch rhythm become your wishlist engine.

What it does not buy you is more time to find the game. If the core loop is still a question mark, EA will convert your uncertainty into public uncertainty. Games that use EA well — Hades, Slay the Spire, Deep Rock Galactic — went in with a loop that already worked and used the time to widen and tune it.

Decide the 1.0 line before you write the roadmap

Write down, in one page, what the finished game contains. Then sort everything else into three buckets and keep them visible to the whole team.

Bucket	Meaning	Roadmap treatment
In 1.0	Ship-blocking. 1.0 is not 1.0 without it.	Named on the roadmap
If it earns it	Only built if EA data or feedback justifies it	Never named publicly
Post-1.0 or never	Good ideas with no room in this project	Logged, not promised

The discipline is in bucket two. Every feature a player asks for loudly feels like bucket one by week five. Write the criterion that would promote it — "co-op moves to In 1.0 only if session length is the top-three complaint and we have twelve weeks of slack" — and you convert an argument into a check you can run.

This is the point where a structured doc earns its keep. If your 1.0 definition lives in the GameDesignerX milestones module, with the roadmap items as objectives hanging off it, the question "is this in scope?" has one answer instead of three remembered differently.

Cadence beats promises

Players forgive a missing feature. They do not forgive silence. The single highest-value commitment you can make is a rhythm, and you commit to the rhythm rather than to contents. Three tiers are enough:

Tier	Frequency	Contains	Version bump
Hotfix	Within 72h of a blocker	Crashes, save corruption, progression stoppers	0.4.2 → 0.4.3
Patch	Every 2 weeks	Bug fixes, balance numbers, small QoL	0.4.3 → 0.5.0
Content update	Every 6–10 weeks	A named feature, biome, class or act	0.5.0 → 0.6.0

Pick numbers you can hit when one of you is sick and the other is at a wedding. A fortnightly patch that is sometimes thin reads as a healthy project. A six-week content update that slips twice reads as a dying one.

Two rules make the cadence survivable:

1. Content updates are time-boxed, not scope-boxed. On the Friday before the update, whatever is not finished gets cut and the update ships with what works. A biome with four enemies instead of six is a shipped biome.
2. Every build gets a number and notes before it leaves your machine. When a player reports that the elite spawn rate feels broken, "which build?" must be answerable. Logging each build with its version, changed values and known issues — the build tracking module exists for exactly this — is what makes EA feedback usable instead of anecdotal.

A roadmap that survives contact with players

Delete the quarters. Use three horizons and no dates:

• Now — in the build you are playing, or in the next patch. Two to four items.
• Next — the current content update. Three to five items, all already prototyped.
• Later — direction, not commitments. Phrased as goals: "deeper late-game build variety", not "prestige system with 30 nodes".

Rules that keep it honest: nothing enters Next until it exists in some playable form; nothing in Later uses a feature name a player could hold you to; and every item moves exactly one step per update or gets visibly removed with a sentence explaining why. A roadmap that shrinks on purpose, with reasons, builds more trust than one that only grows.

Turning feedback into a queue

Forums, Discord and reviews produce an unsorted stream. Run it through the same funnel every week:

1. Collect — one pass through reviews, the bug channel and the suggestions channel. Twenty minutes, timer on.
2. Classify — bug, balance number, missing affordance, or feature request. Most "the game is too hard" reports are missing affordances, not balance.
3. Count — tally repeats. A complaint from fifteen people in one week outranks a beautifully argued post from one.
4. Route — bugs to the issue log, numbers to the balance sheet, requests to the idea log with their promotion criterion attached.
5. Answer in public — a short "patch notes: because you told us" line on the three biggest items. Players who see their report in notes report again.

Step four is where teams leak. If feature requests land in a Discord channel nobody re-reads, you will rebuild the same argument in month four. Routing them into the idea and issue logs — one entry, one owner, one decision — is the whole trick.

The six-week loop, as a checklist

• Week 1: ship content update, publish notes, update roadmap horizons
• Week 1–2: hotfix window — expect two or three, do nothing else ambitious
• Week 2: feedback pass, re-tally the request counts
• Week 3: patch (balance + QoL), plus first playable of the next content item
• Week 4: internal playtest of the next content item with five fresh players
• Week 5: patch, feature-complete the content item, cut what is not done
• Week 6: polish, write notes, prepare roadmap move — then repeat

Exit criteria for 1.0

Decide these at EA launch, not when you are exhausted:

• Every In 1.0 item is shipped, or formally cut with a decision logged.
• Core loop complaints have dropped out of the top three in reviews for two consecutive updates.
• Crash rate and progression-blocker reports are near zero across a full content update.
• Localisation, achievements and the final store page are done — not "planned".
• You have a marketing beat left in the tank for the 1.0 launch.

Early Access is not a longer development period. It is development with an audience watching, which means its real deliverable is the rhythm: a build they can name, a note that tells them what changed, and a plan that gets smaller and more honest every time you touch it.