How to build a UGC creator marketplace with Lovable

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 docs.lovable.dev, checked August 2026.

Only the first three are needed to start, and none of it touches your computer. From here, you describe what you want and Lovable builds it in the browser.

1. 01

   Connect Supabase before you ask for a single screen

   The most common way a Lovable build goes sideways is designing screens first and adding the database later. Connect it from the chat now, and every screen after this has somewhere real to write to.

   PromptConnect the backend and set the ground rulesCopy

   Connect this project to Supabase before we build anything. Once it is linked, note the conventions for the rest of this build: this is a two-sided UGC marketplace, so we will use brands, campaigns, applications, submissions, licences, wallets, and payouts as the names throughout. Two rules to hold to from here: every screen reads and writes real Supabase data rather than placeholder content, and anything that changes a wallet balance happens in a server-side function, never in the browser.

   Connect it first and Lovable designs tables as it goes. Connect it later and you rebuild the screens that were saving nowhere.

2. 02

   Describe the tables, including the ones that hold money

   Ask for the whole model in one message, money included. Describe wallets vaguely and you get a balance column somebody can overwrite, which is the one shape you cannot audit later.

   PromptDesign the marketplace data modelCopy

   Design the database for this marketplace. Brands are the buying side and creator profiles the selling side, each attached to an account. Campaigns hold a title, brief, deliverable format, the rate paid per accepted submission, how many slots there are, a deadline, and a status covering draft, active, paused, completed, cancelled, with the funded budget tracked separately from the rate. Applications link a creator to a campaign with their own status. Submissions link an application to an uploaded video and move through draft, submitted, under review, approved, rejected, revision requested. Licences are created when a submission is approved and record which channels, for how long, whether it is exclusive, and when it was granted. For money, give each creator a wallet with a balance, and a transactions table where every credit and debit is its own row, so the balance is always the sum of that history rather than a number anything can overwrite. Show me the tables and how they relate before you build any screens on them.

   Say the balance is the sum of its transactions out loud in the prompt. Left unsaid, you get an editable number and no way to prove what it should have been.

3. 03

   Bookmark this version, then add logins and the two sign-up paths

   Changes to the data model and the access rules are the ones worth being able to undo in a click. Bookmark first, then ask for the roles and both onboarding flows in one message.

   PromptAdd auth and the three rolesCopy

   Bookmark the current version first, then add authentication. Email-and-password sign-up, login, logout, and a profile row per account. Then three roles (creator, brand manager, and admin) stored in their own table rather than on the user account itself, because anything on the account can be edited by the person it belongs to. Add a helper the access rules can call to check a role without the rule calling back into itself. Then split sign-up in two: a creator fills in a creator profile, a brand creates or joins a brand, and each lands on a different dashboard.

   Bookmarking before a change to the data model is the difference between one click back and a long scroll through history.

4. 04

   Ask for the access rules, then check them with the audit prompt

   This is the step that decides whether one creator can read another’s earnings. Ask for it explicitly, including the video files and the wallet, and then have Lovable read its own work back to you in simple terms.

   PromptAdd row-level security and storage rulesCopy

   Turn on row-level security for brands, creator profiles, campaigns, applications, submissions, licences, wallets, and transactions, using the role helper. An admin can reach everything. A brand manager can reach their own brand, its campaigns, and the applications and submissions on those campaigns. A creator can reach only their own profile, applications, submissions, wallet, and transactions, and can read an active campaign without seeing anyone else who applied to it. Every insert and update needs an explicit check that the new row belongs to whoever is making it. Wallets and transactions must not be updatable or deletable from the browser at all, since balances may only move inside a server-side function. Then apply the same care to the uploaded videos: the submissions bucket must not be public, and a file should be readable only by the creator who uploaded it, the brand whose campaign it belongs to, and an admin. Then show me how to confirm one creator gets nothing back when they query another creator's transactions.

   Uploaded video sits outside the tables, so it needs its own rules. Here the file is the thing being licensed, so a public bucket is an unlicensed copy waiting to happen.

5. 05

   Build the creator side, then the brand side, in that order

   Two messages, previewed separately. Start with the creator flow: it contains the upload, which is the single most fragile screen in the product.

   PromptBuild the creator sideCopy

   Build the creator side first: a board of active campaigns showing what each pays and how many slots are left, a campaign page with an apply action, and an upload screen for submitting video. The upload has to handle large files by sending them in chunks so a dropped connection resumes rather than starting over, and it has to show real progress rather than a spinner. Assume it is being used on a phone on bad wifi, because it will be.

   PromptBuild the brand sideCopy

   Now the brand side: a form to create and edit a campaign, 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 kept on the record for both sides. Use Select elements to point me at anything you want me to adjust rather than describing where it sits.

6. 06
   Destination

   Make approval pay the creator, then run both sides in the preview

   Close the loop from approval to a licence and a paid creator, then use the preview from two accounts. The second side is the one you will otherwise never test.

   PromptAdd licences, payouts, and testCopy

   Add the rights and money layer, all of it in server-side functions rather than in the browser. When a brand approves a submission, one action should grant the licence on that campaign's terms and credit the creator's wallet with the rate, together, so neither can happen without the other. Add a withdrawal request that queues a payout, and make the payout safe to run twice so a retry cannot pay someone a second time. Give the admin side a finance view of what is owed, paid, and stuck. Then walk me through the whole thing in the preview 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, check the licence and the wallet both moved, and request a withdrawal.

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.

One button, and the app you have been previewing is live.

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.

You bring no key and pick no provider: Lovable manages an API key per project, and if you do not name a model it chooses one from what you describe. Match the model to the job: fast and cheap for anything that runs on every record, stronger only where the reasoning matters. Send every feature above through that one integration.