Lead Product Designer · 2022 → present Co-led v1 with a peer · solo from v2, PM-led roadmap
Timeline
2022 → present 4+ years
Team
w/ PMs, Eng leads Front, Back, SDK
Scope
Publishing, Payments, Analytics, RBAC
Type
B2B platform SaaS · Dev tools
— What I owned
End-to-end design across v1 → v3 — co-led v1 with a peer, solo from v2 onward. IA, flows, components, RBAC model, six-store compliance spine.
— Worked with
PM-led roadmap · Eng leads on front, back, and SDK. 1 peer designer (v1 only). Built on top of Float — the multi-brand DS I'd already shipped.
v3: one dashboard, six stores
FIG. 01 / OVERVIEW
studio.now.gg
DASHBOARD · v3
● LIVE
now Studio
The short version.
Full story · ~11 min read below
Problem
now.gg’s cloud needed games at scale, but our team loaded them one at a time. Devs had no self-serve way to publish, test or get paid.
My role & team
Lead product designer, 2022 to now. Co-led v1 with a peer, solo from v2, PM-led roadmap, with front, back and SDK engineering leads.
What shipped
Three overhauls: a self-serve bridge, a 5-bucket publishing surface, then a multi-store dashboard with payments, analytics and RBAC.
Outcome
6 storefronts from one upload. 60+ studios and 100+ titles live, 7,000+ devs. Time to publish went from 4–5 days to one sitting.
§00Where it stands, today.2026 · in flight
One Studio build reaches six storefronts; 60+ studios and 100+ titles ship through it today.
6
Storefronts from one dashboard
Cloud Store · BlueStacks Store · Huawei AppGallery · Amazon Appstore · OnePlus OneStore · Xiaomi GetApps. One Studio build reaches all six.
60+
Studios shipping today, growing each cohort
Mobile game studios actively publishing through Studio — solo founders, mid-size teams, and 50-person operators all on one surface.
100+
Titles published through Studio
Published mobile titles that have shipped to at least one of the six channels through Studio since v1 went live.
— 4 years · 3 overhauls · 1 designer leading from idea to live product.
§01The problem. Why now Studio had to exist.setup · 2022
now.gg's cloud needed games at scale, but the catalog couldn't grow on hand-loading one build at a time.
now.gg had built cloud infra streaming Android games to millions of browser users — but the catalog couldn't scale on hand-holding. Devs, meanwhile, were locked into Google & Apple's economics with no native way to test on cloud or reach a browser-first audience. The bet behind Studio was simple: bring your game to now.gg, get cloud distribution, better unit economics, and visibility your old stores didn't give you.
Signal · 01
now.gg's cloud play needed games at scale — and our internal team was the bottleneck loading them one at a time.
Signal · 02
Indie devs were paying Apple & Google a 30% cut on every IAP — with no native way to opt out.
Signal · 03
Pre-launch testing was the dev's problem: zip the build, share over Drive, lose feedback in Discord.
Signal · 04
Cloud was a new paradigm for game devs — and no existing tool helped them reach a browser-first audience.
01 — DISTRIBUTION
Cloud reach, day one
Publish to now.gg and stream Android games to millions of browser users — no app install, no platform gatekeeping.
02 — REVENUE
Keep more of every IAP
Drop in the Payments SDK and bypass the 30% storefront cut. Per-deal terms, but always meaningfully lower than Apple or Google.
03 — VISIBILITY
Analytics devs didn't have
Sessions, users, IAP revenue, retention — surfaces the closed storefronts didn't give devs access to in any usable form.
04 — TEST
Real cloud, before launch
Test the build on real cloud infra, generate gated test links, pull tester feedback inline — all in the same flow as publish.
§02Three overhauls. Four years. How the product evolved.2022 → 2026
v1 was the self-serve bridge, v2 carved the surface into five buckets, v3 hid six stores' compliance behind one flow.
Each version responded to a different signal. v1 was the bridge — turn now.gg's scaling problem into a self-serve product devs would adopt. v2 was the surface re-architecture — too many features, one dashboard, devs drowning. v3 was the compliance layer — six storefronts behind one flow, hidden complexity, operational unlocks.
— Before / After
From a copy-paste pipeline to self-serve in a single sitting.
The inherited v0 was an internal tool — our team loaded every build by hand, 4–5 days per studio. v3 is the dashboard a dev sees today: six storefronts, one compliance flow, role-scoped, template-driven.
v0 · 2021 · Inherited
An internal tool. Our team published builds for studios by hand. 4–5 days per build, every step manual.
v3 · 2024 · Shipped
Self-serve dashboard. Devs onboard, publish, monetize, measure — all in a single sitting. Six storefronts behind one flow.
Three overhauls, 2022 → now
01 / 03
v1 · 2022 — The bridge
A self-serve route onto now.gg cloud. Decision: scale the surface.
v1 · 2022THE BRIDGE
A self-serve route onto now.gg cloud.
Co-led with a peer designer · inherited a legacy Studio v0 · built on top of Float Studio and the Float multi-brand DS I'd shipped earlier.
Signal
now.gg's cloud bet needed games at scale, but our internal team was loading every title by hand. Meanwhile, devs had Android games trapped inside Google/Apple's 30% economics with no native cloud-test path. The bottleneck was structural.
What we built
A self-serve dev platform — sign up, add the build, test on real cloud infra, publish to now.gg, drop in the Payments SDK for IAP cut savings, manage IAPs, watch session & revenue analytics. Onboarding kept to the basics so devs could be live in a single sitting.
What we learned
Devs came for the cloud distribution; they stayed for the analytics and the IAP economics. The trade — game on now.gg in exchange for visibility & better unit economics — actually worked.
Decision
Scale the surface. The bridge worked; the platform should be more than one channel.
v2 · 2023THE BUCKETING ERA
Five buckets per app — so devs stopped drowning.
Solo designer · PM-led roadmap · iterating directly with eng leads.
Signal
v1 worked — devs joined faster than planned, and features kept compounding on a flat per-app surface: BlueStacks publishing, HTML games, localised IAPs, tester management, custom Webshop, Discord bot, richer analytics. The breaking point was multi-track APK testing — its UI couldn't fit the existing surface without burying everything else. The structure had to change before the next feature shipped.
What we built
The biggest design move of v2 wasn't a feature — it was an IA reorg. Per-app surface carved into 5 buckets: Publish · Payments · Webshop · Traffic · Analytics. Each dev type — publisher, monetizer, growth marketer — found a clear home. Onboarding got reworked to collect intent up front and route devs straight to the bucket they came for. A sample app (based on a small test game I designed) shipped alongside, so every flow had a working demo.
What we learned
Bucketing is what kept the product readable as it scaled. Every new feature found a home; no feature crowded out another. The mental model devs already had — publish, monetize, grow, measure — finally matched the surface.
Decision
Keep adding distribution. The surface can hold it now.
v3 · 2024 → NOWTHE COMPLIANCE LAYER
Six storefronts, one compliance flow.
Solo designer · PM-led roadmap · added Role Management this cycle.
Signal
Each new storefront brought its own policy: listing format, asset specs, regional regulations, review cycle. Publishing to six stores meant holding six compliance models in your head. Repeat publishers — studios with 5+ titles — were re-doing the same setup every launch. We needed a shared spine with per-store branches, not six parallel flows.
What we built
Cloud Store + BlueStacks + Huawei AppGallery, Amazon Appstore, OnePlus OneStore, Xiaomi GetApps from one dashboard — per-store compliance hidden behind a consistent flow. Plus operational unlocks: APK library, APK signing, no-code Payments for studios without engineering capacity, localised publishing assets, RBAC, and pricing/IAP templates so a launch never starts from zero.
What we learned
The biggest unlock wasn't adding more stores — it was hiding their compliance differences behind one flow. Devs don't want to learn six storefronts; they want to ship a game.
Decision
Keep extending compliance surface. Samsung Galaxy Store is next.
CH 01
Cloud Store
Powered by now.gg
CH 02
BlueStacks Store
Powered by now.gg
CH 03
Huawei
AppGallery
CH 04
Amazon
Appstore
CH 05
OnePlus
OneStore
CH 06
Xiaomi
GetApps
FIG. 02 · The publishing dashboard, v3
About this: the main dashboard — list of apps with channel-status pills, primary CTA (New publish), side nav.studio.now.gg / home
§03Four decisions, and the paths we killed.Craft + Tradeoffs
Four calls; two came from killing a path — the six-tile onboarding grid and the quick-publish wizard.
CALL · 01
Onboard for the one goal a dev came for.
× 6-card grid→ Two-step modal⇆
Six tiles read as six things to learn; two steps land the dev in one bucket.
Carving the surface into 5 buckets was the easy part. The trade-off was day-one onboarding — show all the doors, or pick the right one.
Considered, killedA 6-card “pick your job” grid
Six tiles at sign-up: Test my app · Take my app live · Add IAP products · Get more users · Add Payment SDK · Promote my app. Zero gating — but ~90% of devs only need 2 of the 6. The full grid read as “six things to learn”. Wrong tax in the first session.
ShippedTwo-step modal · goal + basics
Step 1 asks app type (Android · HTML5) and the one thing they want first — Publish, Test, or Webshop. Step 2 collects metadata they'd need anyway (title, package, publisher, genre, language). The dev lands in the bucket they came for; the rest stay one click away.
CALL · 02
Per-step pages with save & resume — not a wizard.
× Quick-publish wizard→ 6 steps · save & resume⇆
One linear wizard couldn't carry six policy trees; six pages with resume can.
Publishing touches 40+ fields across 6 storefronts. Whatever the flow looks like, devs would start it, get blocked, and come back hours or days later.
Considered, killedWizard-style quick-publish
A “ship in 5 minutes” wizard with smart defaults and the bare minimum upfront. Worked for one storefront. As Huawei, Amazon, OnePlus, Xiaomi and BlueStacks landed, the wizard couldn't carry six policy trees in a single linear flow without collapsing back into the wall it was meant to avoid.
Shipped6 dedicated steps · save & resume
Each step its own page with smart defaults and inline per-store policy callouts. Devs leave mid-flow and come back to the same step — no lost progress. Lower per-screen density, full per-store coverage.
CALL · 03
Treat IAPs & pricing as a spreadsheet, not a form.
Devs don't have 4 IAPs — they have 40, across 30 markets. The form pattern collapses fast.
ShippedMatrix-first pricing + reusable templates
Bulk-edit by region, copy across tiers, save price & inventory templates for new launches. The template piece is the move I'm proudest of in this section — it shaved most of the boilerplate work off every subsequent app a studio published.
CALL · 04
Roles that map to real teams, not abstract policies.
Generic RBAC treats permissions as a flat checklist. Game studios think in roles.
ShippedPermission scopes around team archetypes
QA, Finance, Marketing, Producer — per-app, per-flow scopes, with unsafe defaults impossible to choose accidentally. Net effect: a 12-person studio can onboard a new QA in 2 minutes without giving them keys to the billing console.
— Shipped, in detail
The calls above, as actual product surface.
Below: the 6-step publishing flow (CALL · 02), the IAP & pricing matrix and reusable templates (CALL · 03), and the role-based access model (CALL · 04) — as they exist in the live product.
FIG. 03 · publishing flow — 6 stepsdrop a video on any step
The six-step publish flow
01 / 06
01 · Publisher details
Email, privacy policy, terms, optional custom domain — attached to every release.
01
Publisher · setup
Publisher details
Email, privacy policy, terms of service, and an optional custom domain — the basics that get attached to every release.
02
Geographies
Regions
Pick the geographies to publish in — regulations and per-region availability are surfaced inline so devs can't accidentally ship into a blocked market.
03
Store listing
Listing & assets
Provide title, description, and screenshots — or one-click import from an existing Google Play listing. This was the largest friction-reducer in v1.
04
Distribution
Channels
Choose which stores to deploy to: Cloud Store, BlueStacks, Huawei AppGallery, Amazon Appstore, OnePlus OneStore, Xiaomi GetApps. One config; six storefronts.
05
SDK · optional
Integration
Add the now SDK for analytics, IAP, and telemetry — or skip it and run with your own stack. The SDK is opt-in, never enforced.
06
Ship
Bundle & publish
Upload the APK or AAB, review the assembled release across every selected channel, and publish — atomically, all at once.
Bulk pricing across regions, saved once and reused.
The IAP list with bulk pricing-by-region — devs edit a matrix, not a form. Inventory & price columns save as templates that ride along to every subsequent launch the studio publishes.
FIG. 05 · roles & permissions, per-appstudio.now.gg / team
Roles that map to real game-studio teams.
QA, Finance, Marketing, Producer — permission scopes built around archetypes, per-app and per-flow. Unsafe defaults are impossible to choose accidentally.
§04Outcomes, not outputs.signal · honest
7,000+ devs publish self-serve to six storefronts; publishing went from 4–5 days to one sitting.
Three measurable shifts after the rewrite:developer adoption, the unit economics of player IAP spend running through nowSDK, and the multi-storefront reach Studio unlocked for now.gg. Numbers below are the last clean reads at handover.
Revenue economics
30% (Apple / Google)→0–5% on nowSDK Payments
~$300K/month in player IAP spend now flowing through nowSDK Payments across 200+ studios. The platform fee sits in a 0–5% band against the 30% standard on Apple / Google — the line item that justifies the integration on its own.
Adoption
1 studio per release cycle (v0)→7,000+ devs, fully self-serve
7,000+ developers signed up, published, and managed their games end-to-end without a hand-off. 200+ went deep enough to ship with nowSDK Payments integrated — the slice generating the IAP volume above.
Distribution
Time-to-publish4–5 days→a single sitting
Storefronts1 storefront→6 storefronts
Platform position“Third largest distribution after Apple & Google.”
One Studio build now reaches six storefronts in a single sitting — Cloud, BlueStacks, Huawei AppGallery, Amazon Appstore, OnePlus OneStore and Xiaomi GetApps. Studios like Tactile Games (Lily's Garden) extended a single APK across PC, Mac and Cloud without rebuilding. The “third largest distribution” claim is now.gg's — but Studio is the on-ramp behind it.
A platform should make the complicated thing feel like the obvious one.
— Studio's design north-star, taped above the Figma file
§05More surface area.Analytics · Test links · Discord bot
The listing devs already filled in feeds a hosted Webshop; a Discord bot and analytics close the loop.
A ready-made Webshop, built from the store listing devs already filled in.
The same listing assets devs uploaded for their app — icon, screenshots, description, IAP catalogue — auto-populate a hosted Webshop template for their game. One config doubles as a direct-to-player storefront. Inviting testers uses the same surface: add emails, scope a build, ship a link.
DAU, sessions, IAP revenue and retention — time-range filter, headline cards, retention chart and per-channel breakdown.
§06What I'd do again, what I wouldn't.Honest self-review
I'd design the unit of work again, and trust clean UI in branchy domains less.
PMs took the major calls; my job was to surface the alternatives, run the testing rounds, and ship the option they chose. And v1 didn't start from zero — it sat on top of a legacy Studio v0, the Float multi-brand DS, and Float Studio (the platform layer I'd shipped earlier). Listed below: what worked, and what I'd push harder on next time.
FIG. 09 · the template that outlived the flowstudio.now.gg / iaps
+
Kept
What I'd do again.
01
Design the unit of work, not the screens.
v0's unit was “our team puts a build out for a studio.” v3's unit is “the dev publishes their own build.” That power transfer was the actual win — the 4–5 days → single sitting outcome was a side effect. Every CALL got sharper once I asked the unit-of-work question first.
02
Permissions scoped to responsibility, not to features.
CALL·04's role management let studios restrict what each teammate could actually see and touch inside Studio. A founder could let a QA lead test builds without ever opening billing; Finance saw IAP revenue without the publishing pipeline; Marketing edited listings without unlocking distribution. The unlock wasn't naming the roles — it was scoping access to map real studio responsibilities.
03
Templates are the compounding asset.
Most design output dies after one ship. CALL·03's pricing, listing and role templates survived every subsequent launch a studio published — boilerplate-killers for every app a studio added. Find the artifacts that outlive the flow.
−
Pushed harder next time
What I'd change.
01
Elegant ≠ right.
CALL·02's killed wizard was the prettier UI. It worked perfectly against one storefront. It broke the moment real-world complexity — six storefronts × N policies — hit it. I should be more suspicious of clean UI in branchy domains.
02
Prioritize by real signal, not user-type completeness.
I tried too often to design a “happy flow” for every user type — every path getting equal weight in the UI. The honest move is to read the data, find the modal user's actual blocker, and make that affordance the loudest one in the flow. Other paths live as drill-down. CALL·01's 2-step modal worked because it did exactly this; I should have applied the same instinct elsewhere earlier.
03
Pull eng + PM in for constraints, not just review.
The wizard in CALL·02 got prototyped before eng surfaced how branchy the per-store policy logic actually was. Same story for a handful of v1 patterns that had to be rewritten once load-bearing tech constraints landed late. Bringing the tech reality in at the sketch stage shrinks the solution space honestly — and saves the rebuild after the prototype is already glossy.
