Building Fanvue's App Store & Developer Platform
The developer platform and App Store that gave Fanvue's third-party ecosystem a proper foundation.
What we set out to do.
- App Store V1 launched on schedule
- 30 app submissions before public launch
- OAuth2 migration complete
Role & Ownership.
End-to-end design of the builder flow, creator-facing App Store, monetisation UI, and app surfaces. I ran the UX/copy audit that identified the gaps and owned the fixes through to launch sign-off.
- End-to-end design of the builder flow (developer profile → app creation → OAuth → events → pricing → publish)
- UX for the creator-facing App Store (browse, install, subscription management)
- Monetisation UI: pricing plans, billing model communication, per-creator callouts
- Design sign-off required across all screens before launch
Why did we build this?
Agencies and power creators were already building on Fanvue through raw API keys: no scoping, no revocation, no trust model. There was no official way to publish a tool, no storefront for creators to find one, and no way for Fanvue to capture revenue from the ecosystem it was enabling.
The platform had the ingredients of a marketplace. It just didn't have the system.
No legitimate distribution channel, no in-platform monetisation, no feedback loop.
No curated, trusted place to find tools. Just word of mouth.
No defensibility. Any competitor could replicate the core product. An ecosystem is much harder to replicate.
Two sides, one platform.
The App Store initiative had two interdependent sides:
- The API + Builder side
- The App Store side
The two sides only work together. 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 authorization. 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.
Developer profile → app creation → OAuth setup → events/webhooks → pricing → publish.
Designed for developers, navigable by non-engineers.
Developer Profile
Builders register as individuals or companies. Verification (KYC) gates access to the full flow.
OAuth Configuration
Client ID, masked client secret with regeneration warning, redirect URLs. Status updates to "Configured" once a URL is saved. Authentication docs linked directly.
Events & Webhooks
Individual webhook rows per event type, each with its own endpoint URL, test delivery, and delivery history. Signing secret visible and copyable. OAuth scope requirements surfaced contextually.
Pricing
Free/Paid toggle. Monthly subscriptions only (V1). Up to 5 plans per app. Price range: $3.99–$500/month. 80/20 revenue split (80% builder / 20% Fanvue) clearly communicated. Per-creator billing model called out explicitly. No agency ambiguity.
Publish & Submit
3-step progress indicator. App logo, name, tagline, description, preview images, test credentials for reviewers. "Submit for review" disabled with inline explanation until all requirements are met. 10 business day SLA communicated. App Store preview before submission.
How creators find and install apps.
Browse by category, read descriptions and permissions, install in one step. Billing terms upfront: monthly, per-creator, no partial-month refunds. Subscription management shows plan, cost, next billing date, and status in one view.
Only verified creators can install. Only approved apps are listed.
The review queue is managed by the Fanvue Team with an In Review → Approved/Rejected workflow.
.jpg&w=3840&q=75)
Billing that works for builders.
V1: flat monthly subscriptions, 80/20 revenue split. Per-creator billing, not agency billing. Required deliberate copy decisions across the pricing page, publish page, and store listing. Every label is a trust signal.
- Pricing plan creation UI (free/paid toggle, plan limits, price validation)
- 80/20 split communication on pricing page, publish page, and store listing
- Subscription install flow for creators
- Subscription management view
- App withdrawal request flow, handled via Fanvue team
Three choices that shaped it.
Keep builder and creator sides separate
Two different audiences, two different mental models. Conflating them would have broken both. Clear separation let each side be designed for its actual user.
Free/Paid toggle over billing interval selector
Monthly-only with up to 5 plans. Simpler, clearer, no complexity neither side needed yet. The original spec had a billing interval dropdown. Mid-project, it shifted to monthly-only. The toggle pattern was cleaner and didn't expose complexity creators and builders didn't need.
"Submit for review" disabled until ready
Builders needed to know exactly what was missing, not just a greyed-out button. A common mistake is hiding disabled states without context. Inline explanation, not a generic disabled button.
Notes to self.
“Platform design is org design. The system only works if the teams are aligned too.”
“Copy is UX. Half the audit fixes were labels, not flows.”
“Billing is trust. Every callout is a signal.”
“Design for the builder who isn't an engineer.”
