How to build an event ticketing system with v0

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, 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

   Sketch the storefront first, because that is what v0 leads with

   Screens with placeholder events, in one chat. The point is to look at the path from browsing to buying before anything is stored anywhere.

   PromptSketch the storefrontCopy

   Build the public screens for an event ticketing platform in Next.js, using placeholder data for now. A browse page with search and a date filter. An event page showing the dates it runs, each ticket type with a name, a price, and how many are left, and a quantity picker that respects a maximum per order. A checkout summary. An order confirmation. Include one event with early-bird and standard prices on the same date, so I can see how two tiers read on one page. Keep it responsive, because most of my buyers arrive on a phone from a link somebody shared.

   Use Design mode for the visual corrections rather than describing them. Spacing, emphasis, and how prominent the price is are exactly what it is for, and describing them in words costs messages you would rather spend on the order logic.

2. 02

   Connect the database and let the screens read real events

   The hand-off. Add the integration from the project menu, then ask for the schema and the routes that replace the placeholders.

   PromptModel the events and connect the databaseCopy

   I have connected a Supabase integration to this project. Design the schema and the routes that read it, then replace the placeholder data in the screens you already built. Organisations own venues and events. An event carries a title, description, image, status, and its organisation. A performance is one date of an event with a start time, a door time, and a capacity, because an event can run more than once. A ticket type belongs to a performance and carries a name, a price, an allocation, a sold count, and a maximum per order. Seed two organisations and three events between them, one with two price tiers on the same date. Write server-side routes for browsing and for a single event, and wire the existing pages to them. Nothing writes yet.

   Do this before building any more screens. Everything after this point either reads or writes real rows, and a screen designed against placeholder shapes gets rebuilt the moment the real ones differ.

3. 03

   Ask for the order route, and make it refuse to oversell

   The first thing here that writes, and the hardest thing in the build. Give it its own chat, because you may need to restore a version and you do not want the storefront coming back with it.

   PromptBuild the checkout that cannot oversellCopy

   Start a new chat for the order path. Two tables: an order, which records which performance it is for, who bought it and at what email address, whether it is pending, confirmed, or cancelled, whether it came from the website or the counter, and what it came to. A ticket points at one order and one ticket type. Now the part that decides whether any of this works. Write a database function that takes a row lock on the ticket type, compares its allocation with the sold count, and inside a single transaction either writes the order, writes its tickets, and raises the sold count, or writes nothing and returns a reason. Reading what is left and writing the order afterwards is the thing I am asking you not to do. Reach it only through a server-side route, so no browser ever touches that count. Pending orders expire after a hold window, released by a job you also add. Finish by firing two orders at the last two tickets simultaneously and telling me what each one got back.

   Keeping this in its own chat is the practical part of the advice. Version history here is one straight line per chat, so restoring an earlier order attempt in a chat that also holds your storefront takes the storefront back with it.

4. 04

   Roles and access rules, in a separate chat

   Buyers, staff, and admins over the same tables, with every rule checking the organisation too. Its own chat again, and its own pull request.

   PromptAdd auth, roles, and access rulesCopy

   New chat, for authentication and access rules. Add email-and-password sign-up, login, logout, and a persisted session. Add three roles (buyer, staff, admin) in a separate table rather than on the account record, since anything stored there is editable by its owner, with one security definer function to check a role and another to check organisation membership. Then row-level security across organisations, events, performances, ticket types, orders, tickets, and scans, every rule checking role and organisation together: a buyer reaches only their own orders and tickets, staff reach their own organisation’s events and may sell and scan but not touch prices or takings, an admin is confined to their own organisation. Explicit with-check clauses on inserts and updates. Then prove it by querying as a buyer and showing me that another buyer’s orders and another organisation’s events come back empty.

   Open the pull request for this one on its own rather than piling it on top of the order work. Access rules are the change you most want to be able to read as a single reviewable diff later.

5. 05

   The door as its own chat: scanner, tickets, and till

   The one part of this build that is not really an interface problem, on the tool that leads with interfaces. Be explicit about what belongs on the server.

   PromptBuild the doorCopy

   New chat for the door. Start with the ticket itself: each one gets a code nobody could arrive at by looking at another one, presented as a QR on a "My tickets" page the buyer can open whenever they like, downloadable. Then the scanning screen, restricted to staff, driving the device camera. It reads a code, hands it to a server-side route, and puts the verdict on screen in type somebody can read while holding the phone at arm’s length: let them in, already used and here is when and on which device, that is for a different event, or that one was refunded. Both the checking and the marking-as-used belong in the route rather than the component, and the route has to behave correctly when the same code arrives twice in the same instant. Then handle losing the network: keep that event’s valid codes on the device, decide from that copy while the connection is down, hold the scans in a queue, settle up on reconnect, and raise a flag over anything that turns out to have gone through twice. Last, a counter till for people arriving without a ticket, drawing on the same stock as the website and able to take cash.

   Say "in the route, never in the component" explicitly and check the diff for it. A scanner is a screen, and a tool that generates screens first will happily put a decision on the device that has to live on the server.

6. 06
   Destination

   Refunds and reports, then merge and deploy

   The back office, a full rehearsal on a real phone, and only then the merge that publishes it.

   PromptAdd the back office and rehearseCopy

   Last chat. Refunding and exchanging both belong in server-side routes. Refunding kills the tickets on an order, hands their stock back to the allocation they came from, and leaves a record of who authorised it and on what grounds. Exchanging voids what the buyer held, issues fresh tickets with fresh codes, and squares up whatever difference in price that created. After those, the admin pages covering events, orders, payments, and venues, and the reporting: what each ticket type sold, what that came to, scanned against sold, and how arrivals were distributed across the evening, all four available as CSV. Then walk an entire event with me from one end to the other, starting at publishing it and finishing with the reports, and including at least one ticket presented twice and one order refunded, so I can see both the failure path and the stock coming back.

   Do the rehearsal before you merge, not after. Merging is what puts this in front of buyers if your base branch is the one the linked Vercel project deploys from, and a scanner is not something to test in production.

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.

Any of these will serve the app. Three things to check here rather than one. Does the plan allow commercial use? Vercel’s Hobby tier does not, and you are taking money. Can it publish from a private repository, given the code sits beside an app holding your buyers’ contact details. And does it give you HTTPS on a real domain, which on this build is a functional requirement rather than a nicety, for the reason below.

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.

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.