How to build a UGC creator marketplace with v0

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, v0.app, v0.app and vercel.com, checked August 2026.

The database step is the one worth not skipping once your screens need real data. Everything else here takes a couple of minutes, and after that you’re just describing what you want.

1. 01

   Generate the campaign board before anything else exists

   Start with the screen creators see first. It is the fastest way to find out whether your campaign fields are the right ones, and it costs nothing to throw away.

   PromptSketch the campaign boardCopy

   Build a campaign board for a UGC marketplace: cards for each open campaign showing the brand, the brief in a line, the deliverable format, what it pays per accepted submission, how many slots are left, and the deadline, with filters for format and budget and an apply button on each. Use placeholder data for now. I will connect a database next.

   Placeholder data is fine here, and only here. Everything after this step gets something real behind it.

2. 02

   Add the database, the tables, and the routes together

   This is the deliberate second step v0 is built around. Connect a database from the project menu, then describe the model, and ask for the routes in the same breath, or the schema sits there with nothing reading it.

   PromptConnect a database and design the modelCopy

   Connect a Supabase database to this project, then create the tables this board needs and the API routes that read and write them. There are two sides, each attached to an account: brands buy and creator profiles sell. A campaign belongs to a brand and holds the brief, the deliverable format, how many slots there are, the deadline, the rate paid per accepted submission, and a funded budget kept as its own figure, plus a status moving through draft, active, paused, completed, cancelled. An application is one creator against one campaign. A submission hangs off an application, points at an uploaded video, and travels through draft, submitted, under review, approved, rejected, revision requested. A licence is created at the moment of approval and states the channels, the term, the exclusivity, and the timestamp. Money is two tables: a wallet per creator carrying a balance, and a transactions table where each credit and debit is a row, so that balance can always be recomputed from its history. Then replace the board's placeholder data with real reads through those routes.

   The transactions table is worth insisting on now. A balance column added first is a number you can never reconcile afterwards.

3. 03

   Start a new chat for auth and the three roles

   Permissions are a feature of their own, so give them their own chat, so restoring a version later undoes the permission work without taking the board with it.

   PromptAdd auth and the three rolesCopy

   In this chat, add authentication and the role model. Email-and-password sign-up, login, logout, a session, and a profile row per account. Then three roles (creator, brand manager, and admin) held in their own table rather than on the user record, since anything on the user record can be edited by that user, plus a helper the access rules can call without recursing. Fork the sign-up: a creator completes a creator profile, a brand creates or joins a brand, each landing on their own dashboard. Every API route must check the role and the ownership server-side rather than trusting anything the browser sends, and no route may accept a wallet balance from the client at all.

   v0 routes run on the server, so the check belongs there. A permission enforced only in the component is a permission anyone can skip.

4. 04

   Put the same rules in the database, and on the video files

   The route check is the first line. Row-level security is the second, and it is the one that still holds when a route forgets to filter, which matters more here, because the row it forgot might be somebody’s earnings.

   PromptAdd row-level security and storage rulesCopy

   Turn on row-level security on brands, creator profiles, campaigns, applications, submissions, licences, wallets, and transactions, so the database enforces the same thing the routes do. Admins are unrestricted. A brand manager is scoped to their own brand: the campaigns under it, and the applications and submissions those campaigns received. A creator is scoped to themselves (their profile, what they applied to, what they submitted, and their own wallet and transaction history) and can browse an active campaign while never seeing who else applied to it. Every insert and update needs an explicit ownership check. Wallets and transactions take no client-side update or delete at all. Balances move only inside a server route. Apply the matching rule to stored video: the submissions bucket must not be public, and a file must be fetchable only by its creator, the brand whose campaign it belongs to, and an admin. Then show me how to confirm one creator querying another creator's transactions comes back empty.

   Two layers on purpose: a route can be bypassed by a bug, a database policy cannot.

5. 05

   Build the upload and the review queue, then tidy with Design mode

   The upload is the screen that decides whether creators finish what they started, so it gets its own chat and a proper pass at phone width.

   PromptBuild the upload and review screensCopy

   In a new chat, build the two screens the work actually flows through. For creators: an upload that sends large video in chunks through a server route so a dropped connection resumes rather than restarting, with real progress and a clear confirmation that the submission arrived. For brands: a review queue that plays each submission back and offers approve, decline, or request a revision with a written reason stored against the submission and visible to both sides. Make sure the upload works at phone width.

   For visual fixes on these two, select the element in the preview and use Design mode rather than describing where it sits. It is faster and it changes the real code.

6. 06
   Destination

   Wire approval to the licence and the wallet, then open a pull request

   Finish the money loop, click it through as both sides, and merge, which, if that branch is the linked Vercel project’s production branch, also deploys it.

   PromptAdd licences, payouts, and shipCopy

   Add the rights and money layer as server routes only. Approving a submission must grant a licence on that campaign's terms and credit the creator's wallet with the rate in one database transaction, so neither half can land alone. Add a withdrawal request that queues a payout and a payout route that is safe to call twice, so a retry cannot pay anyone a second time. Add an admin finance view of what is owed, paid, and stuck. Then help me walk the whole flow (post a campaign as a brand, apply and upload as a creator from a second account, request a revision, approve the next version, confirm the licence and the balance both moved, request a withdrawal), and once it holds up, publish and open a pull request for it.

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.

v0 doesn’t ship its own model for these prompts, so you bring an API key for whichever provider you want, and v0 writes the route that calls it. Start with a cheap model while you’re still iterating on the prompt itself, then swap in a stronger one for the version that ships, and keep every AI feature behind that one route so there’s only one key to rotate.