Building Fanvue's App Store & Developer Platform
Building Fanvue's developer platform from zero. Sole designer across builder and creator surfaces.
Shadow ecosystem to governed platform.
V1 soft-launched to a first group of builders. In the opening three weeks the review gate did its job instead of rubber-stamping: 68 builder submissions, 17 live, 32 rejected, and 19 in queue.
Sole designer on a two-sided platform.
Fanvue is a creator economy platform headquartered in London: paid exclusive content, AI-powered creator tools, and a rapidly growing compliance surface.
- Co-created the product definition, there wasn't one
- Defined the submission and review lifecycle
- Designed both sides end to end, builder and creator
A problem of trust between strangers.
Two groups who don’t know each other, builders and creators, had to transact through a system that makes both sides feel safe. That’s the same challenge at the heart of any social product.
Why did we build this? Over 1,000 unofficial third-party apps were already in use. Raw API keys, no scoping, no revocation, no trust model.
- No legitimate channel
- No distribution or monetisation
- Shadow tools and Discord DMs
- No trusted source for tools
- No curated discovery
- Account access handed to unvetted devs
- No defensibility
- Every rival looks the same
- An app ecosystem is the piece they can't copy
From a UI ticket into a product definition.
- The project was already being built.
- Called a regroup before building or designing even more
- Surfaced the open questions (pricing, review, access scoping) and pressure-tested them with engineering
- Worked the product direction with Head of Product and the lead PM
- Versioning: ship a new version without taking the live app down
- Billing: platform runs payouts, builders just set a price
- Review: a strict quality bar keeps low-value apps out
- Studied: App Store Connect, Shopify, Stripe, Base44, Lovable, Whop, Slack, Zapier
Before and after.
An initial build was in progress without a product definition. I pressure-tested it with developers from other squads and used their feedback to set direction.
.jpg&w=3840&q=75)
Three rules I designed to.
Two sides, one platform.
Builders need a viable path to creators. Creators need trusted, curated apps. Neither works without the other.
The infrastructure that lets developers build on Fanvue. OAuth2 for secure authorisation. A builder flow handling the full app lifecycle: profile, creation, configuration, pricing, and submission.
The creator-facing storefront where Fanvue users discover, evaluate, and install third-party apps, with a review and approval process ensuring quality and trust.
Five steps, navigable by non-engineers.
Developer Profile
Register as individual or company. KYC gates the full flow.
OAuth Configuration
Client ID, masked secret, redirect URLs. Status flips to "Configured" once a URL is saved. Docs linked in context.
Events & Webhooks
Per-event webhook rows with endpoint, test delivery, and history. Signing secret copyable. OAuth scopes surfaced contextually.
Pricing
Free or paid. Monthly only (V1), up to 5 plans, $3.99-$500/month. 80/20 revenue split clearly communicated. Annual and add-ons were scoped out of V1 to ship monthly well.
Publish & Submit
3-step progress. Submit disabled until all requirements met. 10 business day SLA shown. App Store preview before submission.
How builders submit and update apps.
Moved from a binary submission model to a draft model. Builders draft a v2 while the live app keeps serving. Any edit resets the 10-day review clock.
Inline reasons name exactly what's missing. Submit stays disabled.
Under review, 10 business day SLA shown upfront. No silent waiting.
Reasons returned in plain language so a resubmission is fixable, not a guess.
Approved and live. Any future change is published again through the same review.
Browse, install, manage.
Only verified creators can install. Only approved apps are listed. Billing terms upfront on every step.
First contact. Value and billing terms visible before any commitment.
Cost and cadence confirmed before install.
Lapsed access, with a clear path back to good standing.
Validation.
- Walked the builder flow with engineers outside the project
- Builders already earning on raw API keys
- Soft launch: 68 submissions, 65% rejected. The review gate held.
- Can a builder submit a first app unaided?
- Where do builders stall in the funnel, step by step?
- Do creators grasp billing before installing?
- Can rejected builders fix and resubmit without guessing?
What I'd do differently, and what's next.
- Align stakeholders sooner. PM, head of product, and engineering were out of sync, and it took me days to see how far.
- Plan the community migration into V1, not V2.
- Annual and custom billing intervals.
- Builder analytics: installs, churn, revenue.
- A full changelog on top of version history.
- A real migration plan for the unofficial ecosystem.
Learnings.
“Stopping a build already in progress is harder than starting from scratch. But shipping without a product definition would have cost more.”
“Design for the builder who isn't an engineer. If a non-technical founder can't navigate the OAuth screen, the developer experience has failed its widest audience.”
Moderation clear to creators, faster for teams
Go to case study →