How to build a UGC creator marketplace with Claude Code

Rule of thumb: if the marketplace is your business (you take a margin, you own the relationships, you want your own licence terms), the rented options are a tax on the exact revenue you are trying to build, and owning the platform pays back fast. If you are a brand that simply needs a steady supply of video, buy the videos and skip all of this. The genuinely awkward middle is an agency running creator campaigns for clients on a subscription plus a percentage, because that percentage scales with the part of the business you are already doing yourself.

* Read the storage line before you pick a plan, because this template stores video. The free Supabase tier includes 1 GB of file storage, 500 MB of database, and 5 GB of egress, and pauses a project after 1 week of inactivity. A handful of creator uploads and you are out. Pro, from $25/mo, moves that to 100 GB of storage and 250 GB of egress with daily backups kept for 7 days, and charges $0.0213 per GB of storage and $0.09 per GB of egress beyond it. Payouts and identity checks are billed per use by whoever you route them through, and are the two lines that grow with the marketplace rather than sitting flat.

Both columns end with the platform belonging to you, and with the hundredth brand costing no more to serve than the first. The only thing that differs is whose hours go into it: a developer you pay up front, or your own, spent describing what you want and reading back what arrives.

Prices and rates from supabase.com, developex.com and claude.com, checked August 2026.

Nothing here is worth memorizing. These four just need to exist on your machine. From step 01 on, you say what you want and Claude Code runs the commands.

1. 01

   Set up the project

   Get an empty app running against your own database, and hand Claude Code a notes file so it stops inventing new names for a campaign halfway through. One prompt covers all of it.

   PromptSet up the projectCopy

   Set up a new React 18 + Vite + TypeScript project with Tailwind and the Supabase JS client. Read VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key, which replaces the older anon key) from .env, and add .env to .gitignore in the same step so neither value reaches GitHub. Add a typed Supabase client under src/lib, then write a short CLAUDE.md describing the stack and the vocabulary for a two-sided UGC marketplace (brands, campaigns, applications, submissions, licences, wallets, payouts), so later edits stay consistent with the first ones.

   Gives Claude Code a project and a memory to work against.

2. 02

   Model both sides and the money at the same time

   The temptation is to model campaigns and submissions now and bolt payments on later. Do it in one pass instead: a wallet added afterwards means revisiting every row that should have been recording an amount.

   PromptDesign the marketplace data modelCopy

   Create the core data model as Supabase migrations. A brands table for the buying side and a creator_profiles table for the selling side, both keyed to an account. A campaigns table (title, brief, deliverable format, rate per accepted submission, number of slots, deadline, and a status through draft, active, paused, completed, cancelled) with the funded budget tracked separately from the rate. An applications table joining a creator to a campaign with its own status. A submissions table joining an application to an uploaded file, carrying a status through draft, submitted, under review, approved, rejected, revision requested. A licences table written when a submission is approved, recording the channels, the term, whether it is exclusive, and the timestamp it was granted. And the money side: creator_wallets holding a balance per creator, and a transactions table where every credit and debit is a row, so a balance is always the sum of its history rather than a number somebody edits. Write the migration SQL, let me review it, apply it, then regenerate the TypeScript types.

   The rule worth insisting on: a balance is never a column somebody writes to. It is the sum of a transaction history you can read back.

3. 03

   Add sign-in that knows which side someone is on

   One account system, three roles, and a sign-up flow that forks in two. A brand and a creator need different profiles behind the same login.

   PromptAdd auth and the three rolesCopy

   Add Supabase Auth with email and password: sign-up, login, logout, a persisted session, a profiles row per account, and a useUser hook. Then create an app_role enum with 'creator', 'brand_manager', and 'admin', and a user_roles table linking a user_id to a role, kept out of the user's own metadata so nobody can promote themselves. Add a SECURITY DEFINER function has_role(_user_id uuid, _role app_role) that reads user_roles without recursing. Then split onboarding in two: a creator signing up fills in a creator profile, a brand signing up creates or joins a brand, and the app routes each to their own dashboard from the first screen. Put the schema changes in one migration.

   Roles live in their own table for one reason: anything stored on the user account can be edited by the person that account belongs to.

4. 04

   Lock it down before a real video or a real balance exists

   This is the step where a marketplace either keeps two sides apart or quietly does not. Read what comes back rather than skimming it, and note that the uploaded files need rules of their own.

   PromptAdd row-level security and storage rulesCopy

   Enable row-level security on brands, creator_profiles, campaigns, applications, submissions, licences, creator_wallets, and transactions. The rules are these. An admin reaches everything. A brand manager reaches their own brand, its campaigns, and the applications and submissions attached to those campaigns. A creator reaches their own profile, their own applications and submissions, and their own wallet and transactions and nobody else's. A creator can read an active campaign but not its other applicants. Name the WITH CHECK clause explicitly on every insert and update. Make creator_wallets and transactions insert-and-select only from the client: no client-side update or delete at all, since balances may only move through a server-side function. Then do the same for Storage: the submissions bucket must not be public, and a file is readable only by its creator, the brand that owns the campaign, and an admin. Put it all in a migration, then show me how to verify that one creator querying another creator's transactions comes back empty, and that a submission URL from a campaign the account has nothing to do with fails to download.

   Locking the tables and leaving the video bucket public is the version of this that looks finished and is not. Here the file is the asset somebody is buying a licence to.

5. 05

   Build the campaign board, the upload, and the review

   Now the three screens the product lives in. The upload is the one to be specific about: creator video is large, and the connection it arrives over usually is not good.

   PromptBuild the screensCopy

   Build the core screens against these tables. For creators: a campaign board listing active campaigns with the rate and slots left, a campaign page with an apply action, and a submission upload that handles large video files in chunks so a dropped connection resumes rather than starting over, showing real progress. For brands: a campaign create-and-edit form, an applications view for shortlisting and accepting creators, and a review screen that plays a submission back and offers approve, decline, or request a revision with a written reason attached. Keep all data access in typed hooks, and make sure a creator never sees another creator's application to the same campaign.

6. 06
   Destination

   Make one approval do both jobs, then walk it end to end

   The last step is the one that makes it a marketplace: approval has to grant the licence and credit the creator as one action, not two that usually both happen. Then run the whole thing as both sides.

   PromptAdd licences, payouts, and testCopy

   Add the money and rights layer as server-side functions the browser can only ask, never instruct. When a brand approves a submission, one function grants the licence recorded against that campaign's terms and credits the creator's wallet with the campaign rate, in a single transaction, so neither can happen without the other. Add a withdrawal request that queues a payout, and a payout function that is safe to run twice. A repeat call must not pay anyone a second time. Give the admin console a finance view of what is owed, paid, and stuck. Then run the app and walk me through the full flow as both sides (post a campaign as a brand, apply and upload as a creator from a second account, request a revision, approve the second attempt, confirm the licence exists and the wallet moved, then request a withdrawal), then fix anything that breaks on the way.

Review the access rules (row-level security policies) on every table. For each one, tell me in simple terms who can view, add, edit, and delete records, confirm that people can only reach their own data while the right roles can reach more, and flag anything left open that shouldn’t be.

The one rule that matters: no secret key (database, payments, identity, mail, or AI) ever goes into the app or a public repo. If one does get out, treat it as compromised and rotate it the same day.

All of them will serve this app, and the front end is the cheap half whichever you pick. What is worth checking before you commit: whether the plan you are on allows commercial use at all, since Vercel’s Hobby tier says plainly that it does not, and what happens to your bill once creators are uploading video and brands are streaming it back.

Add a server-side function that runs on every new submission, sends the video’s frames and transcript to your ai function, and returns a moderation verdict with a confidence score and a short reason. Store it against the submission, sort the review queue by it, and never auto-reject on it alone. Anything flagged goes to a person with the reason attached.

Add a “Improve this brief” action on the campaign form that sends the brand’s draft to your ai function and returns a structured brief (what to show, what to say, what to avoid, deliverable format and length, and the usage rights being asked for), presented as an editable draft the brand confirms rather than something saved automatically.

Add a “Suggest a shortlist” action on the applications view that sends the campaign brief and each applicant’s profile and past accepted submissions to your ai function, and returns a ranked shortlist with one line of reasoning per creator. Show it as a suggested order the brand can ignore, and never hide unranked applicants.

When a brand requests a revision, add an action that sends the brief, the submission, and the brand’s note to your ai function and returns a clearer version of that feedback: specific, tied to the brief, and phrased as changes to make. Show it to the brand for approval before it reaches the creator, and keep both versions on the record.

Each prompt above picks the model that fits the job. As a rule of thumb, that is Haiku for high volume, Sonnet for everyday writing, and Opus for deeper reasoning. Model names move faster than this page does, so check the current list in the Claude docs (linked in the references below) before you build. Send every one of these prompts through that same ai function, so one key and one set of rules governs all of them.