DEV Community

Cover image for Building a Creator Marketplace with Next.js and Supabase: Lessons from the Trenches
Footly
Footly

Posted on

Building a Creator Marketplace with Next.js and Supabase: Lessons from the Trenches

We're building Footly, a creator marketplace for foot content. Think of it as a niche competitor to platforms like OnlyFans or FeetFinder, but with better creator economics and modern tech.

Here's what we learned building it from scratch.

The Stack

  • Frontend: Next.js 14 (App Router), React, TypeScript, Tailwind CSS
  • Backend: Supabase (Postgres, Auth, Realtime, Storage)
  • Payments: CCBill
  • KYC/Verification: Ondato
  • Hosting: Vercel

We chose this stack for speed. Supabase gives you a lot out of the box - auth, database, file storage, realtime subscriptions - without having to wire up a bunch of separate services.

The Hard Parts

1. Row Level Security for a Marketplace

Supabase's RLS is powerful but gets complicated fast when you have multiple user roles with different permissions.

In a marketplace, you have creators who can only see/edit their own content, buyers who can see public content plus content they've purchased, and admins who can see everything.

A simple "users can only see their own rows" policy doesn't cut it. You end up with layered policies that check ownership, purchase history, and public visibility all at once.

The tricky part is performance. Complex policies with subqueries get expensive on large tables. We ended up denormalizing some data to keep reads fast.

Lesson learned: Plan your RLS policies before you build. Retrofitting them is painful.

2. Dual Wallet System

Creators have two balances: an earnings wallet (money from sales that can be withdrawn) and a spending wallet (money they've deposited for buying other creators' content).

Sounds simple until you realize you need to track every transaction with a full audit trail, handle partial withdrawals, prevent race conditions on concurrent purchases, and calculate pending vs. available balances since payouts have holds.

We ended up building a ledger-style system where every money movement is an immutable transaction record, and balances are computed from the ledger. More complex upfront, but way easier to debug when something goes wrong.

3. Real-Time Messaging with Pay-Per-View

The messaging system needed to support pay-per-view content. A creator sends a message, attaches content, sets a price - buyer has to pay to unlock it.

Supabase Realtime made the basic chat easy. The tricky part was handling the PPV unlock flow atomically. When a buyer clicks unlock, we need to verify their balance, deduct from their wallet, credit the creator's wallet, update the message state, and push realtime updates to both users - all without race conditions.

We wrapped the entire flow in a database transaction to ensure consistency. If any step fails, everything rolls back.

4. CCBill Integration

If you're building anything adult-adjacent, your payment processor options are limited. Stripe will shut you down. CCBill is the industry standard but their documentation is... vintage.

Key things we learned:

Webhooks are essential. Don't try to rely on redirect parameters. Users close browsers, connections drop. Trust the webhook.

Test environment is different. Their sandbox doesn't perfectly mirror production. Budget time for production debugging.

Tokenization matters. Store payment tokens, not card details. Let them handle PCI compliance.

Chargebacks are your problem. Build good content verification and communication features to minimize disputes.

5. KYC Without Killing Conversion

Every creator needs ID verification - it's a legal requirement for adult content. But every friction point in onboarding kills conversion.

Our approach: let creators set up their profile and browse the platform before verification. We only require KYC when they try to publish content or withdraw money. This gets them invested in the platform before hitting them with the friction.

We integrated Ondato's SDK for a smooth in-app verification flow with real-time status updates so creators aren't left wondering if their submission went through.

Things We'd Do Differently

Start with a monorepo. We split frontend and backend early and regretted it. Shared types would've saved hours of debugging type mismatches.

Build admin tools earlier. We hacked together admin functionality as needed. Should've built a proper admin dashboard from day one.

Load test the realtime features. Supabase Realtime is great until you have many concurrent connections and realize you haven't optimized your subscription patterns.

Current Status

We're live with 750+ creators on the waitlist and onboarding the first cohort now. The tech is holding up, but we're sure there are more lessons coming as we scale.

If you're building a marketplace or working with similar tech, happy to answer questions in the comments.


Check out Footly if you're curious about the end product.

Top comments (0)