How to build a UGC creator marketplace with OpenAI Codex

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 learn.chatgpt.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 Codex runs the commands.

1. 01

   Write AGENTS.md before anything is scaffolded

   Codex reads AGENTS.md at the start of every task, so writing it first means your vocabulary is loaded before there is any code to be inconsistent with. A marketplace has two sets of nouns, which makes this worth more here than usual.

   PromptSet up the projectCopy

   Start by writing an AGENTS.md at the project root: the stack is React 18, Vite, TypeScript, Tailwind, and the Supabase JS client, and this project is a two-sided UGC marketplace. Fix the vocabulary in it (brands, campaigns, applications, submissions, licences, wallets, payouts) and note the rule that money only ever moves in server-side functions, never from the browser. You load that file automatically at the start of every later task, so nothing in it needs repeating by hand. Then scaffold the project itself: a typed Supabase client under src/lib reading VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key that replaced the older anon key) from .env, with .env confirmed present in .gitignore. Start the dev server once to prove it boots before you stop.

   Putting the money rule in AGENTS.md rather than in one prompt is what keeps task five from cheerfully writing a balance update straight from a component.

2. 02

   Get the campaign, submission, and ledger shapes right in one task

   Have Codex write the migrations for both sides and the money at once, and ask to see the SQL before it runs. A wallet retrofitted later is the expensive version of this.

   PromptDesign the marketplace data modelCopy

   Write the Supabase migrations for the core of a two-sided UGC marketplace. Brands are the buying side, creator_profiles the selling side, each keyed to an account. Campaigns carry a title, brief, deliverable format, rate per accepted submission, slot count, deadline, and a status through draft, active, paused, completed, cancelled, with the funded budget tracked separately from the rate. Applications join a creator to a campaign and carry their own status. Submissions join an application to an uploaded file and move through draft, submitted, under review, approved, rejected, revision requested. Licences are written on approval and record the channels, the term, whether it is exclusive, and when it was granted. For the money: creator_wallets holds a balance per creator and transactions holds every credit and debit as its own row, so a balance is the sum of its history rather than a figure anybody overwrites. Print the SQL for me before it runs, and regenerate the TypeScript types once it is applied.

   Ask for the ledger in this task, not a later one. Adding transactions after the fact means backfilling history for balances that were only ever a number.

3. 03

   Narrow permissions, then build the two sign-up paths

   This task touches authentication, which is exactly the kind of change worth scoping Codex down for rather than leaving the wider settings you would use for routine edits.

   PromptAdd auth and the three rolesCopy

   This task touches authentication, so narrow your permissions to just this one rather than keeping whatever you had set for routine edits. Wire in Supabase Auth for email-and-password sign-up, login, logout, a persisted session, a profiles row per account, and a useUser hook. Then the role model: an app_role enum of 'creator', 'brand_manager', and 'admin', with a user_roles table linking a user_id to a role, kept in its own table rather than on the account, since anything stored on the account is editable by the person it belongs to, plus a SECURITY DEFINER function has_role(_user_id uuid, _role app_role) that reads it without recursing. Then fork onboarding: a creator completes a creator profile, a brand creates or joins a brand record, and each lands on their own dashboard. One migration, and walk me through the diff before it runs.

   Two sign-up paths, one account system. Building them as two separate apps is the decision that doubles every change you make afterwards.

4. 04

   Read this diff properly: it is the one holding two sides apart

   Row-level security across every table, matching rules on the uploaded video, and a client that cannot touch a balance at all. Of every diff in this build, this is the one to actually read rather than approve on trust.

   PromptAdd row-level security and storage rulesCopy

   Turn on row-level security across brands, creator_profiles, campaigns, applications, submissions, licences, creator_wallets, and transactions. An admin reaches every row. A brand manager reaches their own brand, its campaigns, and the applications and submissions attached to them. A creator reaches only their own profile, applications, submissions, wallet, and transactions, and can read an active campaign without seeing who else applied to it. Give every insert and update its own WITH CHECK clause. Then close the money path from the client side entirely: creator_wallets and transactions get select and insert policies at most, with no client-side update or delete, because a balance may only change inside a server-side function. Carry the same thinking into Storage: the submissions bucket must not be public, and a file must be readable only by the creator who uploaded it, the brand whose campaign it belongs to, and an admin. Once it is applied, walk me through proving all of it: one creator querying another's transactions should come back empty, and a submission URL from an unrelated campaign should refuse to download.

   Table policies, storage policies, and the client's write access to the ledger are three separate things. It is entirely possible to get two right and leave the third open.

5. 05

   Point Codex at the screens, a few files at a time

   The campaign board, the upload, and the review screen are what both sides judge this on. Codex only needs the files each screen touches, not the whole project.

   PromptBuild the screensCopy

   Now the screens, on top of what is already there. For creators: a board of active campaigns showing the rate and how many slots are left, a campaign page with an apply action, and an upload that sends large video in chunks so a dropped connection resumes instead of restarting, with honest progress while it does. For brands: a form to create and edit a campaign, an applications view for shortlisting and accepting, and a review screen that plays the submission and offers approve, decline, or request a revision with a written reason that both sides keep. Data access stays in typed hooks rather than spread through the components, and no screen should ever surface one creator's application to another.

6. 06
   Destination

   Make approval move the licence and the money together

   The last piece is the one that makes this a marketplace rather than a file drop. It is also a long, well-scoped task, a reasonable one to hand to a cloud run, provided you read the diff before it merges.

   PromptAdd licences, payouts, and testCopy

   Add the rights and money layer as server-side functions only. Approving a submission must, in one database transaction, grant a licence against that campaign's terms and credit the creator's wallet with the campaign rate. Neither half may land without the other. Add a withdrawal request that queues a payout, and a payout function that is safe to call twice, so a retried request cannot pay anyone a second time. Give the admin side a finance view of what is owed, what has been paid, and what is stuck. Then run the app and take it end to end yourself (post and fund a campaign as a brand, apply and upload as a creator from a second account, request a revision, approve the next attempt, check the licence row and the wallet both moved, and request a withdrawal), then fix whatever does not hold up.

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 should pick whichever model tier fits the job: a fast, lower-cost model for high-volume work, and a stronger reasoning model for anything that weighs tradeoffs against each other. Codex’s model names change faster than this page does, so check OpenAI’s current model line-up (linked in the references below) before you build, rather than copying a name you saw once. Keep all of it behind that same ai function, so one key and one rule set covers every feature you add.