Building Fanvue's App Store & Developer Platform
Building Fanvue's developer platform from zero. Sole designer across builder and creator surfaces.
Fanvue is a creator economy platform headquartered in London: paid exclusive content, AI-powered creator tools, and a rapidly growing compliance surface.
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 in the first 3 weeks · 17 live · 32 rejected · 19 in queue
Sole designer on a two-sided platform.
- Created the product definition, there wasn't one
- Defined the submission and review lifecycle, including the draft model
- 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.
Over 1,000 unofficial third-party apps 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
I turned a UI ticket into a product definition.
- The project was already being built.
- Stopped the build and called a regroup before designing anything
- Surfaced the open questions (pricing, review, access scoping) and pressure-tested them with engineering
- Wrote the product direction and co-authored the PRD with the lead PM
Scoped OAuth: a client credential plus granular, revocable permissions per app, not one shared key.
Submit, team review, then go live, with a stated turnaround. This shaped the 10-day SLA.
Submission stays blocked until the listing is complete. The gate names what's missing.
- 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.
From profile to published.
Five steps from profile to published. Designed for developers, 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
- Showed 3 employees already earning on raw API keys the new direction
- 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.
- Get builders testing earlier, not just at the end.
- 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.”
Turned moderation into a tool creators trust
Go to case study →