nowStudio — developer platform for cloud gaming

§00Where it stands, today.2026 · in flight

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

Directional — 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 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

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.

v0Inherited — **v0 · 2021** · Inherited
An internal tool. Our team published builds for studios by hand. **4–5 days** per build, every step manual.

v3Shipped — **v3 · 2024** · Shipped
Self-serve dashboard. Devs onboard, publish, monetize, measure — all in **a single sitting**. Six storefronts behind one flow.

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

CALL · 01

Onboard for the one goal a dev came for.

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.

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

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.

FIG. 04 · IAP & pricing matrix + templatesstudio.now.gg / iaps

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

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.

§05More surface area.Analytics · Test links · Discord bot

FIG. 06 · webshop & testersstudio.now.gg / webshop

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.

FIG. 07 · discord bot configurationstudio.now.gg / integrations

Traffic acquisition without leaving the dashboard.

Setup wizard — connect server, pick channel, configure auto-posts. The Discord bot turns release notes into traffic.

FIG. 08 · analytics dashboardstudio.now.gg / analytics

Real-time signal that closes the publish loop.

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

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.

+

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.

One upload,six stores,zero handoff.

Role

Timeline

Team

Scope

Type

6

60+

100+

Cloud reach, day one

Keep more of every IAP

Analytics devs didn't have

Real cloud, before launch

From a copy-paste pipeline to self-serve in a single sitting.

A self-serve route onto now.gg cloud.

Five buckets per app — so devs stopped drowning.

Six storefronts, one compliance flow.

Onboard for the one goal a dev came for.

Per-step pages with save & resume — not a wizard.

Treat IAPs & pricing as a spreadsheet, not a form.

Roles that map to real teams, not abstract policies.

The calls above, as actual product surface.

Publisher details

Regions

Listing & assets

Channels

Integration

Bundle & publish

Bulk pricing across regions, saved once and reused.

Roles that map to real game-studio teams.

A ready-made Webshop, built from the store listing devs already filled in.

Traffic acquisition without leaving the dashboard.

Real-time signal that closes the publish loop.

Design the unit of work, not the screens.

Permissions scoped to responsibility, not to features.

Templates are the compounding asset.

Elegant ≠ right.

Prioritize by real signal, not user-type completeness.

Pull eng + PM in for constraints, not just review.