Meta Quest Developer Publishing Workflow Redesign
Denis Lesak
Redesigned Meta Quest's developer publishing workflow, reducing Developer Relations support tickets by 62% and increasing developer release velocity by 8% through systems thinking, workflow redesign, and cross-functional alignment.
Meta Quest App Submission workspace — stepper with live validation state and readiness summary separating automated checks from human review.
Quest's submission pipeline sat between every studio and millions of players — and it was opaque. Studios batched updates, delayed launches, and shipped less often. The cost compounded across thousands of developers and every release they didn't make.
Developer confidence
Submission was a black box. Studios couldn't tell whether a release would pass review — so they released less, and prioritized platforms where they could.
Developer Relations spent significant time resolving avoidable submission issues. Their expertise was consumed by repetitive support instead of ecosystem growth.
Review cost
Reviewers repeatedly processed submissions that better validation could have prevented. Every avoidable rejection consumed operational bandwidth.
Publishing velocity compounds — into release cadence, developer trust, ecosystem health, and player retention. Friction here shows up everywhere else.
The Quest publishing surface had been assembled over years by six teams — Store, Build Tools, Compliance, Monetization, Reviewer Ops, and Developer Relations — each shipping their slice into the same console. I mapped the system end-to-end and found there was no shared model of what a "release" actually was. Every surface reported its own status, and none of them answered the only question studios cared about.
am I ready to ship?
I reframed the work around three principles, introduced a shared release object every team could write into, and drew an explicit map of who owned what.
Every check the platform can run should run automatically, where the developer already works.
Studios always see where a submission stands, what's blocking it, and what's next.
One release model,
two connected flows.
The release object as the seam every team writes into. Ownership boundaries drawn explicitly — including the cross-team dependencies that turned out to be the actual work.
I isolated three root causes of uncertainty and pressure-tested each against product, engineering, and organizational constraints. Leadership debated architecture, not UI polish — and converged quickly on the direction that could actually be staffed.
Readiness as a continuous pre-submission state. Every automatable check runs as artifacts land, in parallel, with a clear what/why/fix on every failure.
Continuous validation as the backbone. Transparent review layered on top.
The chosen direction addressed the core user pain, reused existing validation infrastructure, and scoped cleanly within team ownership boundaries — the best balance of developer value, engineering effort, and organizational feasibility.
How I drove the initiative over time — from opaque discovery to a measured, phased launch across six teams.
Reframed submission as ecosystem throughput, not a console UX issue.
I re-framed the console around a continuously updated readiness state. Submission becomes a formality — the moment a studio decides to promote a release that has already been validated.
Initial submission
Upload & validate
Asset-only update
Validation Every failure answers what, why, how to fix it, and how long. "Unsupported image dimensions" is now a specific, resolvable instruction.
Failed state → submit gate The gate only unlocks once automated checks pass. Human review, estimates, and the "green ≠ approved" guard rail are always visible.
Of everything that shipped, the capability studios talked about most wasn't a workflow — it was a preview. Draft metadata rendered through the consumer Store's own pipeline, so studios finally saw their listing exactly as players would, before publish.
PDP preview — draft listing rendered by the consumer Store's own engine.
Developers previously published listings they had never actually seen. The preview lets studios review exactly what players will experience before publishing — improving confidence and reducing avoidable publishing mistakes.
The preview reduces review cycles caused by incorrect assets, layout issues, localization problems, and merchandising mistakes. Review teams spend less time rejecting avoidable submissions, and developers publish with greater confidence.
The gap was organizational, not technical.
The Store team already owned the rendering engine. Developer Platform and Store Platform had never shared this capability. Rather than building a second renderer, I proposed exposing the existing Store engine as a shared platform service. The solution required cross-functional alignment far more than difficult engineering.
The engineering problem wasn't rendering the Store Preview. It was deciding who owned it.
The Store organization already owned the rendering engine. The Developer Platform team owned publishing. Rather than proposing duplicate rendering technology, I reframed the conversation around exposing the existing Store renderer as a shared platform capability.
The hardest problem became organizational alignment rather than implementation. Once ownership became clear, implementation became straightforward.
Six teams owned pieces of the publishing surface. Shipping the redesign required aligning all of them around one shared release model — and, for the PDP preview, convincing a seventh (the consumer Store team) to expose a capability they had never intended to share.
I created the framing and alignment decks and then ran a roadshow — walking each stakeholder group through the reframe until publishing was no longer a console problem but an ecosystem throughput problem. That alignment is what unlocked staffing, the roadmap commitment, and the cross-org partnerships the project needed to have real impact.
The challenge was never rendering the preview. It was organizational ownership.
The Store team owned PDP rendering. Developer Platform owned publishing. Neither team owned "preview" — which is why it hadn't shipped, and why cloning the surface would have created a maintenance liability no one wanted.
The alignment deck reframed the ask: expose the Store's existing rendering as a shared platform service. What looked like a hard engineering problem was really a joint decision. Once both orgs agreed on schema and ownership, the build was small.
What I carry out of this project isn't a redesigned console. It's a way of thinking about platform work.
Products become scalable when every team aligns around shared objects instead of independent workflows. The release object wasn't the most complex thing to design — it was the most contested. Once every team could point to their edge of it, the surfaces followed cheaply.
The hardest work was creating shared understanding across organizations that had shipped their surfaces independently for years. The design artifact that moved the room wasn't a mock. It was a diagram, defended in framing decks and re-drawn until the ownership boundaries were obvious to everyone.
On platform work at this scale, cross-functional alignment isn't a soft skill sitting alongside the design work. It is the design work.
Before this project I believed platform design was primarily about simplifying complex workflows. After it, I understood that the real work begins long before interface design. Platform design is the practice of helping multiple organizations align around shared models, shared ownership, and shared outcomes. Once those foundations exist, interfaces become significantly easier to design.
When I began this project, I believed platform design meant simplifying complex workflows.
By the end, I realized the real work begins much earlier. Platforms become scalable when organizations align around shared models, shared ownership, and shared outcomes. Interfaces become the visible result of that alignment rather than the starting point.
Cross-functional alignment is not work that happens alongside design. At platform scale, it is the design work.
Developers resolved common submission issues without relying on DevRel, freeing the team to focus on strategic partnerships and adoption of new platform capabilities.
Studios shipped updates more frequently because submission became more predictable and review readiness became visible throughout the workflow.
Following this project, Design earned greater trust across the Developer Platform organization and became involved earlier in strategic planning for complex platform initiatives. This work demonstrated that Design could lead platform-wide operational improvements rather than only interface design.
This project improved more than the submission experience. It demonstrated that design could solve platform-wide operational problems — strengthening organizational confidence in Design and expanding its role in future strategic initiatives.
These are the working documents that helped align multiple organizations around a shared publishing model. The finished interface was only one part of the project — the framing decks, system diagrams, and stakeholder maps were equally important design artifacts.
Submission is a
black box.
Developers can't see what will fail, when review will end, or why a build was rejected — until it's too late to fix cheaply.
Review happens once,
at the very end.
Publishing friction
compounds at ecosystem scale.
One release model,
many surfaces.
Six teams,
one surface.
Work shifts upstream
for every team.
Phased delivery.
Each cut ships value.
How we'd know
this worked.
PDP preview alignment deck — Making Store Preview a shared platform capability
The proposal that convinced the consumer Store team to expose their PDP rendering as a shared platform service, and clarified the cross-team seams.
A proposal to expose the consumer Store's existing PDP rendering through a shared service — so developers can preview draft metadata before submission, without duplicating the surface or owning the B2C rendering pipeline.
Developers ship listings
they've never seen.
Metadata, imagery, pricing, and localization are authored in the Developer Portal — but rendered for the first time only after publish, on the consumer Store. Small mistakes surface in front of players, and fixes require another review cycle.
Two concerns, both
about ownership and drift.
Promo modules, pricing surfaces, and localization pipelines are updated on the Store team's rhythm. A cloned preview would drift fast.
The PDP is a template in code.
The gap is access, not technology.
Rendering logic, layout rules, pricing, promos, and localization already exist in the Store's stack. The real work is cross-functional: the Store team must expose and support a draft-capable rendering path, the Developer Portal must consume it, and both teams must agree on schema, versioning, and SLOs.
Two portals, no shared surface.
A support boundary, not a build.
Neither team owns "preview." It sits between them, which is why it hasn't shipped — and why it needs a joint decision, not a single-team build.
Expose the Store's PDP
as a platform service.
Reuse is the only
durable answer.
Clear seams,
clear owners.
Known risks,
each with a lever.
One decision
unblocks the rest.
Confirm the Store team owns and exposes a shared PDP rendering service for draft metadata, and that the Developer Portal consumes it rather than rebuilding a preview. This is the commitment that enables a joint roadmap across B2C and Developer Platform.
Small, sequenced steps
to a shared surface.
Original Oculus App Manager submission flow
Like this project
Posted Jul 21, 2026
Redesigned Meta Quest's developer submission workflow, improving release velocity and reducing support tickets.
