How to build an event ticketing system with Lovable

Rule of thumb: if you need an audience you do not have, buy. A marketplace putting your event in front of strangers is worth a real percentage, and none of it is something an app of your own provides. If your attendees already know who you are, because they follow you, subscribe to you, or come every month, then you are paying a finder’s fee on people you found yourself, and that is the case for building. The arithmetic that settles it is one line: your ticket price, times the percentage, plus the fixed fee, times how many people come. For scale, the Congressional Research Service reports that in 2025 Ticketmaster averaged about $8.91 in revenue for each fee-bearing ticket it sold, not your rate, but a fair sense of what a seat at the top of this market is worth to the company selling it.

* One line on the free tier is worth more attention on this build than on most. Supabase Free comes with 500 MB of database space, 1 GB of file storage, and 5 GB of monthly egress, and it puts a project to sleep after seven days without activity. Look at the traffic shape of a ticketing app (one on-sale, one event night, weeks of silence around both) and that sleep is not an edge case, it is the default state. Pro, from $25/mo, ends it, brings 250 GB of egress (then $0.09 per GB), and keeps a daily backup for 7 days. Free is genuinely fine until you announce something. Announcing is the moment to move.

Neither column takes a cut of a ticket, because the app records orders and whatever payment rail you connect charges its own rate, so the running cost is a database and a host and nothing else. That bill does not move with attendance: forty tickets and four thousand cost the same to host, and the only thing that grows is the traffic on the night.

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 describe a single screen

   Screens built over data that does not exist yet get rebuilt when it does. Connect the database first, and set the two rules the whole build depends on while the chat is still empty.

   PromptSet up the projectCopy

   Connect my Supabase project first, before building any screens. Then set up an event ticketing platform and hold two rules for the rest of this project: what remains of a ticket type is always worked out from its allocation minus what has sold, never stored as a number a screen can write. A ticket can be admitted exactly once, with that check made on the server rather than on whichever phone scanned it. Use these words consistently throughout: organisation, event, performance, ticket type, allocation, order, ticket, scan. Confirm the connection is live and tell me which of those two rules affects how you will design the order tables, before you design them.

   Asking it to tell you how the rules change the design is worth the extra exchange. It is the cheapest way to find out early whether the model it has in mind is a counter it decrements or a count it derives.

2. 02

   Describe the events, and watch the storefront appear

   The part Lovable is fastest at, and the part where seeing it beats specifying it. Get the selling model in front of your own eyes before anything can take money.

   PromptModel the events and build the storefrontCopy

   Design the tables and build the public side over them. Organisations own venues and events. An event has a title, description, image, status, and an organisation. A performance is one date of an event, with a start time, a door time, and a capacity, because an event can run several times. A ticket type belongs to a performance with a name, a price, an allocation, a sold count, and a maximum per order. Add two organisations and three events as sample data, one with early-bird and standard prices on the same date. Then build the storefront: browsing with search and a date filter, and an event page showing the dates, each ticket type with its price and what is left, and a quantity picker that respects the maximum per order. No sign-in and no checkout in this message.

   Click the two-tier event in the preview before moving on. One date carrying two prices is where a ticket model usually first contradicts itself, and here you can see it rather than reason about it.

3. 03

   Ask for the sale to be atomic, in those words

   A preview cannot show you two people buying at once, so this is the one step where you have to specify the behaviour rather than look at it. Ask for the guarantee explicitly and ask to see it proved.

   PromptBuild the checkout that cannot oversellCopy

   Build the order path, and treat this as the most important message in the project. Orders carry a performance, a buyer name and email, a status of pending, confirmed, or cancelled, a channel of online or box office, and a total. Tickets belong to an order and a ticket type. Stock has to move safely: write a database function that locks the ticket type row, checks the allocation against the sold count, and creates the order, its tickets, and the increased sold count in one transaction, or fails with a clear reason. It must never read what is left and then write the order as a separate step. Put it behind an edge function so no browser updates the count directly. Give pending orders a hold window, and add a scheduled job to expire unpaid ones and return their stock. Then show me, by running it, what happens when two orders for the last two tickets arrive at the same instant.

   Bookmark the version before you send this. The order path is the piece most likely to need two or three attempts, and getting back to a known-good starting point beats unpicking a half-changed one.

4. 04

   Three roles, and the policies that read them

   Buyers, the staff who work the door, and the admins who own the organisation. Every rule here checks two things at once, which is what makes this longer than it looks.

   PromptAdd auth, roles, and access rulesCopy

   Add email-and-password sign-up, login, logout, and a persisted session. Add three roles (buyer, staff, and admin) in their own table rather than on the account record, since anything stored there is editable by the person it belongs to, with a security definer function to check a role and another to check whether an account belongs to an organisation. Then turn on row-level security everywhere (organisations, events, performances, ticket types, orders, tickets, scans) with each rule checking role and organisation together: a buyer reaches only their own orders and tickets, staff reach their own organisation’s events and can sell and scan but not change prices or see takings, and an admin is confined to their own organisation. Add explicit with-check clauses on inserts and updates. Then sign in as a buyer in the preview and show me that another buyer’s orders and another organisation’s events both come back empty.

   Ask to see it as a signed-in preview rather than as a summary of the policies. The staff role is the one to test hardest. It goes to the most people, often casually, on the night.

5. 05

   The door, built and previewed on your phone

   Lovable gives you a real URL for the preview, which is the whole point here: open it on the phone your staff will actually hold rather than judging a scanner in a desktop window.

   PromptBuild the doorCopy

   Build the whole door in this message. Ticket issue first: an unguessable code per ticket that cannot be worked out from the one next to it, shown as a QR on a "My tickets" page the buyer can always come back to, with a download. Then the scanner: a staff-only screen using the phone camera that reads a code, calls a server-side function to validate and redeem it, and shows a result readable at arm’s length: admitted, already used with the time and device that used it, wrong event, or refunded. The redemption must happen on the server and must be safe against the same code arriving twice at once. Then the offline case: hold the event’s valid codes on the device, admit against them when the network drops, queue the scans, reconcile when it returns, and flag anything that turns out to have been admitted twice. Then a box office till for walk-ups, selling from the same stock as the website and taking cash.

   Open the preview on a real phone for this one, not in the desktop tab. The camera permission, the brightness, and how a scan feels with one bar of signal are all things the desktop preview will let you believe are fine.

6. 06
   Destination

   Refunds, reports, and a bookmark before you publish

   The back office, then a full rehearsal, and a bookmarked version before you point a domain at any of it.

   PromptAdd the back office and rehearseCopy

   Finish the back office. Refunds and exchanges as server-side functions: a refund cancels its tickets, puts the stock back in the allocation, and records who did it and why. An exchange voids the old tickets, issues replacements with new codes, and settles any difference. Then the admin panel for events, orders, payments, and venues, and reports covering what sold by ticket type, what came in, how many were scanned against how many sold, and when people arrived across the evening, each exportable as CSV. Then take me through a whole event in the preview: publish it, buy two tickets, sell a third at the box office, scan all three on a phone, present the first again, refund one and confirm the stock returned, and check that both reports agree with what I actually did.

   Bookmark the version that passes this rehearsal before you connect a domain or change anything else. It is the last point where you know every part of the app worked together, and it is the one you will want back.

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: the database service key, the secret your ticket codes are signed with, and any payment key you add later never belong in the app or in a public repo. If one of them gets out, assume it is compromised and rotate it that day.

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

Add a "Draft the listing" action on the event form. Send the event name, date, door time, venue, ticket types with their prices, and any notes I have typed to a server-side function calling an AI model, and return a short summary line and a longer description in a tone I choose. Show them as editable drafts rather than saving them, never invent a detail I did not provide (no line-ups, no times, no claims about the venue) and leave anything it was not given blank instead of guessing.

Add a question box on the public event page that answers from that event’s own published details and my organisation’s standing information only, through my ai function. Retrieve the relevant text first and pass it in, keep the answer to what is in that text, and when there is no answer say so and offer the contact route rather than guessing. Never let it state a policy on refunds, entry, or accessibility that is not written in the source it was given.

Add a post-event summary that sends the aggregate figures for one event (tickets sold by type, revenue, how many were scanned in, when the arrivals happened across the evening, refunds and exchanges) to my ai function, and returns a short written read of it: how the sale went, what turnout looked like against what sold, and where the arrival peak fell. Send aggregate numbers only, never attendee names or email addresses, and have it state the figures rather than describing them vaguely.

Put a question box on the admin dashboard that converts a plain-language question about my events into a single read-only lookup and renders the answer as a small exportable table. Constraints, all of them enforced rather than requested: describe the tables to the model instead of sending it any rows, permit SELECT and nothing else, run the query under the signed-in account so the same access rules that govern the rest of the app govern this too, exclude attendee names and email addresses from anything it returns, and print the query beside the answer so I can see what it actually asked.

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.