A dated store window is not the day testing starts. It is the last day a last fix can still ship.
Work backwards from that date. Count the store's own review queue. Then book the QA pass so the first useful bugs land with time left to change the build you will actually submit. If you start when the listing already shows an exact day, you are late.
The date is a queue, not a test plan
Steam, iOS, and Android all publish process. None of them promise that your title will clear on a morning you picked.
On Steam you complete two checklists: store presence, then the product build. You submit the page before you submit the build. Valve's Steamworks review docs say each review typically takes 3–5 business days, and they ask you to plan at least 7 business days so there is room if they send the page or the build back. A new product must also sit as Coming Soon for at least two weeks before you can release it yourself. Once that Coming Soon page is live and you are inside 14 days of the specified date, you cannot change the date without contacting Valve. The date you printed is now a store fact.
On iOS, Apple's App Review page says that on average 90% of submissions are reviewed in less than 24 hours. That is an average, not a slot you own. Incomplete submissions delay or fail. Apple still lists guideline 2.1 App Completeness as the common failure: crashes, placeholder content, broken links, missing demo accounts. Expedited review exists for a critical bug, or for an event you are directly associated with. It is not a launch plan.
On Google Play, personal developer accounts created after 13 November 2023 cannot apply for production until a closed test has had at least 12 testers opted in continuously for 14 days. Google says the production-access review after that usually takes seven days or less, and can take longer. That closed test is a store rule. It is not a substitute for a scoped QA pass, and an external partner is not a way to skip it.
Console certification, where you have it, is the same kind of object: a process with its own gates. It is not a promise, and it is not the same job as testing the PC, iOS, Android, Web, TV, XR, or other emerging-platform build you intend to put in front of players.
Too early and too late are different failures
Too early, you test a private branch. The store page still lists a feature that lives on a spike. IAP is a stub. The first-hour loop will change next week. Steam's build review checks that features listed on the store page exist in the current build. You paid for bugs on a game the store will never see.
Too late, the first useful bug arrives inside Steam's 14-day date freeze, or after the iOS or Android binary is already in review. You still get a tracker full of issues. You do not get a shippable fix. The pass was accurate. The calendar was not.
The useful start is the first week you have a store-shaped build: the features on the listing are in the build, the platforms on the listing are the platforms you will submit, and a programmer can still take a cycle of bugs before you mark that build ready for the store's queue.
Work backwards from the date you cannot slip
Do not plan forwards from "code complete" and hope the queues fit. Reverse the calendar.
- Write the go-live date and the store SKUs on one line. Name PC, iOS, Android, Web, TV, XR and other emerging platforms only if they are truly in this drop. Cross out anything that is a later SKU.
- Subtract the store's published buffers. For Steam, that is Coming Soon of at least two weeks, plus the 7-business-day review planning Valve asks for on both page and build, plus the 14-day date lock. For a new personal Play account, that is 14 days of closed testers plus the access review Google describes as usually seven days or less. For iOS, treat Apple's average as true only if the build is complete. Budget a resubmit if it is not.
- Subtract one programmer fix cycle after the first bugs. If your people cannot turn a blocker in that window, the pass is too late even if the store queue would have fitted.
- Book the external pass so it finishes before you mark the build ready for review. The partner tests the build you will submit, not a branch you will rebase afterwards.
If you registered for Steam Next Fest: October 2026, Valve's own dates are now the calendar. The fest runs 19–26 October 2026. To have the demo live at the start of Press Preview, Steamworks says you should have submitted the demo build and store page for review by 21 September. All required items must be in review by 5 October. A demo is a build. Test the demo you will actually show, on the page players will actually see.
September 2026 is already a busy public Steam calendar of dated full releases and Early Access drops. If your date is on that calendar, the queue math above is the work. Wishlists do not test the build.
What that last pass is for
The last pass is not a tour of the game. It is a check that the store-shaped build behaves like the listing.
- The product starts on every OS you listed.
- The first-hour loop, save/load, and a clean install/reinstall work.
- Features and IAP you claimed on the store page are in this build, not in a later branch.
- Compatibility and configuration on a device matrix you do not keep on the desk, across the platforms named in the brief: PC, iOS, Android, Web, TV, XR and other emerging platforms.
- Performance and regressions that would fail a completeness review, or a player, in the first session.
Say what is out. A certification checklist, where you have one, stays a process you own with the platform holder. An external partner who pretends that checklist is their deliverable is selling the wrong pass.
After Valve has reviewed a Steam build you may keep updating it. They still ask for a near-final build in the queue. Do not use "we can patch later" as the reason to skip the last pass.
Brief the partner against the window
You do not need a novel. You need the rails that make the pass match the date.
- A signed NDA, named contacts, a build channel you control.
- Your tracker as the system of record.
- The exact SKUs and OS versions in this drop.
- The freeze point: which build will be marked ready for review.
- What "done" means, and how much calendar is left for a retest after a blocker.
Send the build the store will see. If save/load, IAP, or multiplayer is in the listing, it is in scope. If a later SKU is not in this window, write that down so nobody tests the wrong product.
Judge the pass in the tracker, against the date. Did the first useful bug arrive early enough to change the submission? Did they retest what they logged? If the date still cannot move, the next conversation is a tighter retest on the resubmit, not a wider tour.
Close
GameCloud Technologies Private Limited is a Pune company. It was founded in Indian financial year 2010-11. We work as an independent video-game QA partner for studios, publishers, producers, and QA leads heading toward a dated store window.
If you already have a date for PC, iOS, Android, Web, TV, XR or any other emerging platform and you need a last pass before that queue, that is a scope conversation. Write to Sales@GameCloud-Ltd.com. We will send a one-page scope. No meeting link required to start.