How to build a UGC creator marketplace with Replit

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 replit.com, checked August 2026.

The first two are all you need to start. Everything here stays inside the one browser tab, the app included once you publish it, and the GitHub copy is the one deliberate exception.

1. 01

   Start the app and ask for the database in the same message

   There is no outside database account to create first, so the database is part of your opening message rather than a separate errand. Ask for a notes file too, so the Agent’s vocabulary carries through the rest of the build.

   PromptSet up the project and the databaseCopy

   Set up a React 18 + Vite + TypeScript app with Tailwind, and add a Postgres database to this Repl. Use the one Replit provisions rather than connecting anything outside. Write a short notes file at the project root saying this is a two-sided UGC marketplace and fixing the vocabulary for the rest of the build: brands, campaigns, applications, submissions, licences, wallets, payouts. Add one standing rule to it: anything that changes a wallet balance happens on the server, never in the browser. Keep the database connection details and any provider keys in Replit's Secrets rather than in the code.

   The database is already part of the workspace, so asking for it is one message, not a separate signup.

2. 02

   Write the schema, ledger included

   Ask for the SQL before it runs. The part worth reading closely is the money: a balance that is a column rather than a sum is the one mistake you cannot audit your way out of.

   PromptDesign the marketplace data modelCopy

   Write the SQL migration for a two-sided UGC marketplace, against the Postgres database already in this Repl. Brands are the buying side and creator profiles the selling side, each attached to an account. Campaigns carry a title, brief, deliverable format, rate per accepted submission, slots, 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. Submissions join an application to an uploaded video and move through draft, submitted, under review, approved, rejected, revision requested. Licences are written on approval, recording channels, term, exclusivity, and when they were granted. Creator wallets hold a balance, and a transactions table holds every credit and debit as its own row, so the balance is always the sum of its history. Show me the SQL before you run it.

   Every credit and debit as a row is what lets you answer “where did this $200 go” months later. A single balance column cannot answer it at all.

3. 03

   Build both halves of sign-in yourself

   Replit’s Postgres is a plain database with no login system wired into it, so the Agent writes both parts: sessions on the server, and a roles table the server checks against before anything reads a wallet.

   PromptAdd sign-in and the three rolesCopy

   Add email-and-password sign-up, login, logout, and a server-side session for this app, with a profile row per account. Then a roles table giving each account one of creator, brand manager, or admin, kept in its own table, never on the account record, since anything there is editable by that user, and a helper the server and the database policies can both call to check it. Then fork the sign-up: a creator completes a creator profile, a brand creates or joins a brand record, and each lands on their own dashboard. Every route that touches a wallet or a licence must read the session on the server rather than trusting anything the browser sends.

   There is no ready-made login handing the database a user id here, so the server is the thing that knows who is asking. Build that first, and the policies in the next step have something to read.

4. 04

   Scope every row to whoever should reach it

   Replit’s Postgres does row-level security like any Postgres. The difference is where the identity comes from: the server sets who is asking at the start of each request, and the policy reads that.

   PromptAdd row-level security and file rulesCopy

   Turn on row-level security across brands, creator profiles, campaigns, applications, submissions, licences, wallets, and transactions. Have the server set the current account's id and role as a session-local setting at the start of every request, then write the policies to read that setting: an admin reaches everything, a brand manager reaches their own brand, its campaigns, and the applications and submissions attached to them, and a creator reaches only their own profile, applications, submissions, wallet, and transactions, able to read an active campaign without seeing its other applicants. Every insert and update needs an explicit ownership check, and nothing outside a server-side function may update or delete a wallet or a transaction at all. Apply the same rule to uploaded video: a stored submission must not be reachable by anyone other than the creator who uploaded it, the brand whose campaign it belongs to, and an admin. Show me how to prove one creator gets nothing back when querying another creator's transactions before we move on.

   Read this one closely. It is the step that decides whether a creator can total up what a rival earned on the same campaign.

5. 05

   Bring both sides online

   The upload and the review screen are what each side judges this on. Check the preview after each rather than approving both and finding out later.

   PromptBuild the screensCopy

   Build the two halves this marketplace runs on. For creators: a board of open campaigns showing the rate and remaining slots, a campaign page with an apply action, and an upload that sends large video in chunks so a dropped connection resumes rather than restarting, with real progress and a clear confirmation, working properly at phone width. For brands: creating and editing a campaign, an applications view for shortlisting and accepting creators, and a review screen that plays the submission back and offers approve, decline, or request a revision with a written reason kept on the record for both sides.

6. 06
   Destination

   Finish the money loop, then publish

   Add licences, wallets, and payouts, walk the whole thing yourself from both sides, then publish, checking who the app is visible to before that first release, since Publishing is what sets it.

   PromptAdd licences, payouts, and publishCopy

   Add the rights and money layer, all of it server-side. An approval has to do two things in one database transaction (write the licence on that campaign's terms, and credit the creator's wallet with the rate), so that it is impossible for one to land without the other. Then a withdrawal request that queues a payout, and a payout routine that survives being run twice, since a retry must never pay the same creator again. Give the admin side a finance view of what is owed, paid, and stuck. Then help me test the full flow from both sides (post a campaign as a brand, apply and upload as a creator on a second account, request a revision, approve the next version, confirm the licence and the balance both moved, request a withdrawal), and when it holds up, walk me through Publishing: which deployment type fits this, and who the app should be visible to.

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.

These are all Replit rather than a third party, so the decision is about shape rather than vendor. Autoscale or Reserved VM carry the app itself, with Reserved VM making more sense once submissions arrive daily. Scheduled is the one to remember when you build the payout run, because paying creators on a fixed date is a much easier promise to keep than paying them the instant somebody clicks. Before that first release, read what Publishing is about to change: the domain, who is allowed to see the app, and what it is going to cost to run.

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.

A cheap model is plenty for most of the prompts above. Save Pro’s stronger models for the one or two spots where the extra reasoning actually pays for itself. Add any provider key through Replit’s own Secrets tool rather than hard-coding it, and keep every AI feature behind one server-side function so a single key covers the whole app.