You’ve locked content. The game runs. QA has signed off. Then someone on your team quietly mentions the cert submission deadline is in three days, and you realize you’ve never actually read the platform holder’s technical requirements document. That moment of cold dread is completely avoidable. It happens more often than anyone in the industry likes to admit. Platform certification has ended careers, delayed launches by months, and cost studios hundreds of thousands of dollars in overtime and lost revenue. It doesn’t have to go that way.

What Platform Certification Actually Is (And Why It Exists)

Certification, usually called “cert” in the industry, is the gatekeeping process platform holders use to ensure titles meet their technical, content, and business standards before appearing on their storefronts. Sony has its Technical Requirements Checklist (TRC). Microsoft uses the Xbox Requirements (XR) document. Nintendo calls theirs Lotcheck. Each one is a living document, updated regularly. Each one has teeth.

The platform holders aren’t doing this to torture you. Their reasoning is practical: one broken game that bricks consoles or exploits payment systems damages the entire platform. Cert is quality assurance at the ecosystem level. When you understand that framing, you stop fighting the process and start working with it.

What’s in these documents? Crash and hang behavior. Save data integrity. Online features and network error handling. Age rating compliance. Accessory support. User account handling. Content policies. Each requirement is numbered, and each one is a potential failure point. A single mandatory requirement failure means a full rejection, which usually means restarting the clock on a two to four week review window. That adds up fast.

Here’s the part producers often underestimate: the requirements change. Microsoft updates XRs regularly. Sony’s TRC evolves between console generations. A cert checklist you used on your last game may be out of date. Always download the current version directly from the dev portal. The version number is in the header. Check it.

Building Cert Into Your Schedule (Not Bolting It On)

Certification PhaseTimelineKey ActivitiesOwnership
Cert Review Pass 1~12-16 weeks before launchFull manual review against platform checklists; document unimplemented requirementsTechnical QA lead
Dev Kit Compliance TestingAlpha through betaSave corruption testing; network timeout handling; suspend/resume failuresQA team
Cert Submission Prep6 weeks before launchFinal requirement verification; prepare build and documentationDev team + producer
Initial Review Window4 weeks minimumPlatform holder review and feedbackPlatform holder
Potential Fix/Resubmit CycleVariableAddress rejection feedback and resubmitDev team
Day-One Patch (if needed)After initial cert approvalLighter cert review process for patchesDev team

Most certification failures are scheduling failures before they’re technical failures. The team never had enough runway to address cert requirements during production, so they’re scrambling at the end.

I’ve seen projects where cert prep was literally a three-day task at the bottom of a milestone plan. Three days for a game shipping on three platforms. That’s not a plan.

Here’s a more realistic model for a mid-size AA title shipping on PS5 and Xbox Series X|S simultaneously:

  • Cert review pass 1 should happen around alpha, roughly 12 to 16 weeks before launch. Assign your most technically literate QA lead to do a full manual review against both checklists. Document every requirement you haven’t implemented yet.
  • Dev kit compliance testing runs continuously from alpha through beta. This is where you catch save corruption, network timeout handling, and suspend/resume failures.
  • Cert submission prep should begin no later than 6 weeks before your launch date. You want 4 weeks minimum for initial review, one potential failure/fix/resubmit cycle, and a buffer for anything unexpected.
  • Day-one patch should be planned in your schedule regardless of whether you need it. Cert for patches goes through a lighter process, but it still takes time.

Jira or Hacknplan with a dedicated “Cert” label applied to any task touching a requirement works well here. Pair that with a shared spreadsheet that maps each TRC/XR line item to the engineer or designer responsible for it. Accountability by name. Not “team” or “TBD.” A person.

The Most Common Cert Failure Reasons (And How to Prevent Them)

Platform holders don’t usually publish failure rate statistics, but anyone who has managed multiple submissions has patterns burned into their brain. These are the areas that catch teams most often.

Network error handling. Your game must gracefully handle losing network connectivity at any moment during matchmaking, mid-transaction, during a save, during a cutscene. Automated testing rarely catches all of these. Manual QA with network simulation tools is non-negotiable. On PlayStation, network error handling requirements are especially detailed.

Save data behavior. Corrupting a player’s save file is among the worst things a game can do. Cert requirements mandate specific behavior when storage is full, when a save is interrupted, and when a save device is removed mid-write. These scenarios need dedicated test cases.

Privilege and parental controls. If your game has online features, in-game purchases, or user-generated content, you must respect platform-level parental control settings. This one fails submissions constantly because it’s easy to implement the feature without wiring it to the platform’s permission check.

Age ratings. You need ratings from the appropriate bodies: ESRB for North America, PEGI for Europe, CERO for Japan. You can’t submit without them. Rating applications take time, sometimes 4 to 6 weeks. If you forgot to start that process, you’re already behind.

Localization and content policies. Specific platforms and regions have rules about what can and can’t appear in content. Nintendo’s Lotcheck is particularly thorough about in-game text and visual content. If you’re shipping in Germany, Japan, or Australia, know those regional rules before you finalize content.

Step-by-Step: Running Your First Cert Submission

If you’re a producer running a certification submission for the first time, here’s the sequence that works.

  1. Download the current requirement document from the official dev portal. Do this the day you start cert prep, not the day before submission.
  2. Create a requirement tracking sheet. List every requirement by ID. Add columns for status (pass/fail/N/A), assigned owner, notes, and date verified. Share it with your leads.
  3. Hold a cert kickoff meeting. Walk your engineering and QA leads through the document section by section. Let them self-identify risks. You want them flagging problems, not you discovering them at submission.
  4. Run a focused cert build. At least two weeks before submission, produce a build specifically tested against cert requirements. This isn’t your regular QA build. It has cert-specific test cases.
  5. Complete the submission questionnaire accurately. Platform holders ask you to declare what features your game uses: online play, in-game purchases, camera/mic support. If you declare a feature that doesn’t work, that’s an automatic failure. If you omit a feature that’s in the game, that’s also a failure. Be precise.
  6. Submit during business hours, early in the week. If you hit a technical issue with the submission portal on a Friday afternoon, you’re losing two days. Monday morning gives you a full business week of support access.
  7. Prepare your failure response plan before you hear back. If cert comes back with failures, you want to be able to fix and resubmit within 48 to 72 hours. That means having your cert engineer available and a tested build pipeline ready to go.

Understanding the Difference Between Cert and Platform Review

These two processes are often conflated and they shouldn’t be. Certification is technical and process-focused. Platform review (sometimes called store review or content review) is business and content-focused: does your game’s store page comply with content policies? Is your trailer appropriate? Does your game description accurately represent the product?

Both can block your launch. Both have their own timelines. For a digital-only title, you typically need to submit your store assets (screenshots, description, trailer, pricing) at least two to three weeks before release. On consoles, store approval and cert are separate processes that sometimes run in parallel.

Use a tool like Monday.com or Notion to build a pre-launch checklist that covers both tracks, not just cert.

Comparing the Three Major Platform Cert Processes

Sources

PlatformDocument NameTypical Review TimeResubmission WaitPortal
PlayStation (PS5/PS4)TRC (Technical Requirements Checklist)2 to 4 weeks1 to 2 weeksPlayStation Partners
Xbox (Series XS / One)Xbox Requirements (XR)2 to 4 weeks1 to 2 weeks
Nintendo SwitchLotcheck2 to 5 weeksVariesNintendo Developer Portal

Nintendo’s Lotcheck process tends to be the most detail-oriented of the three. The review is thorough, turnaround can be slower, and requirements around content and technical behavior are strictly enforced. Budget extra time for Nintendo submissions, especially if it’s your first Lotcheck.

Certification doesn’t reward heroics at the end of a project. It rewards diligence throughout. The producers who ship on time aren’t the ones who got lucky in cert. They’re the ones who treated the requirements document like a design constraint from day one, assigned real ownership to each item, and built their schedules around the reality of the process rather than the hope of skipping it. Start early, stay specific, and never assume your last game’s checklist still applies. The platform holders will update their requirements whether you’re watching or not.

Photo: Pavel Danilyuk via Pexels