Steam Coming Soon Page Checklist Before You Go Public

Before you publish a Steam Coming Soon page, verify that its promises match the game you intend to ship, its artwork and text follow Valve's store rules, and the review timeline leaves room for corrections. For a small indie team, the useful standard is not "the page looks finished." It is "every claim has an owner and evidence." You can prepare a Coming Soon page before the final game build is ready; you cannot safely market features that may never ship.

Decide when the page is ready to represent the game

A Coming Soon page is useful once your team can communicate the game's genre, core experience, and visual direction without relying on guesses. Valve's Coming Soon guidance recommends going public when you are ready to talk about the game, while warning that substantial later changes may confuse people who wishlisted the earlier concept.

Use three preflight decisions:

• GO: the core promise is stable, necessary public assets are ready, and claims can be checked against the production plan.
• FIX: the promise is stable, but a specific screenshot, description, or asset needs correction.
• HOLD: the headline mechanic, target platform, or feature set is still speculative enough that the page would misrepresent the eventual release.

This gate is editorial advice, not a Valve-defined status. A HOLD should trigger a narrow prototype or design decision—not weeks of polishing unrelated material.

Valve says the store presence checklist must be completed and the page approved before it can go public. Its review-process documentation says store-page review typically takes 3–5 business days and recommends submitting at least seven business days before the desired public date. Budget time for corrections; a typical duration is not a guaranteed deadline.

Give every store-page claim a production receipt

The highest-risk mistake is treating aspirational design as a launch promise. Valve reviews whether features and content shown on a store page will be available at launch. Content planned for later must be clearly identified as unreleased, and the page cannot imply that unfinished functionality is already part of the purchase.

For each player-facing claim, record:

• Claim: the exact phrase or feature shown on the page.
• Evidence: playable build, approved design scope, or current production proof.
• Owner: who can confirm it before review.
• Decision: keep, reword, identify future content clearly, or remove.
• Recheck date: when the team must confirm the claim still holds.

Do this for supported platforms and input modes too. "Full controller support" and "online co-op" shape player expectations and must match what you intend to deliver.

A dependency sweep before your next milestone helps when a store promise still depends on an outsourced asset, network feature, or platform test. If the evidence will not arrive before review, remove or revise the claim rather than silently betting on it.

Check art and copy against Steam's actual rules

Do not rely on a generic marketing checklist. Valve's store-page description guidance says the short description should convey what is distinctive about the game, avoid time-sensitive slogans, and stay focused on the product. The longer description must not contain external website links or fake Steam-interface buttons.

Before submission, check the assets as a first-time visitor would:

• Screenshots show real gameplay rather than concept art, pre-rendered cinematic stills, awards, or promotional text.
• The capsule logo remains readable at the sizes where players will see it.
• Base capsules contain the game artwork, title, and optional official subtitle—not review scores, awards, "Wishlist now," or other marketing copy.
• The short description identifies the genre and main player action without unexplained internal terminology.
• Store feature flags, written claims, screenshots, and trailer footage tell the same story.

The screenshot and content restrictions come from Valve's review criteria; the capsule restrictions are specified in its graphical asset rules. A striking visual does not override a compliance problem.

Run a 30-minute review with one accountable owner

Hypothetical example: a three-person studio is building a local co-op puzzle game. Its draft page promises "online co-op," the screenshots include a cinematic prototype shot, and the capsule says "Wishlist now." The programmer confirms networking is not committed for launch. The artist can replace the shot with gameplay, and the writer can remove the capsule call to action.

The team records HOLD for the unsupported online feature claim and FIX for both assets. They change the description to accurately describe local co-op, replace the screenshot, clean the capsule, then review the complete page again. Only then do they submit the store presence for Valve review.

Copy this handoff into your production plan:

Page target date:
Submission owner:
Promise audit: GO / FIX / HOLD; evidence link
Copy and store flags: GO / FIX / HOLD; reviewer
Screenshots, trailer, capsules: GO / FIX / HOLD; reviewer
Steamworks checklist: completed / blocked
Review submission date:
Valve feedback owner and correction deadline:
Approval confirmed: yes / no
Person responsible for posting publicly:

A page with no named publishing owner can remain invisible after approval. According to Steam's Coming Soon procedure, approval is followed by a separate "Post as Coming Soon" action. For new products, the page must also be public for at least two weeks before the game releases. That is separate from approval.

Make the announcement depend on the approved page

Do not promise a public announcement date solely because the artwork is done. First clear the claims, assets, checklist, and Valve review; then have the assigned person confirm the page is actually visible. Keep post-approval changes consistent with what the team can deliver.

For your next announcement, make a small playable milestone or store-page readiness milestone with clear owners and evidence. In PlayablePlan, you can track approval work as tasks linked to a milestone, so the public page follows verified production decisions rather than optimistic copy.