How to build an event ticketing system with Claude Code

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 claude.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 Claude Code runs the commands.

1. 01

   Boot the project, then write down the two rules

   A running app pointed at your own database, and a CLAUDE.md holding the two constraints every later step is going to lean on.

   PromptSet up the projectCopy

   Set up a new React 18 + Vite + TypeScript project with Tailwind and the Supabase JS client. Read VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key, which replaces the older anon key) from .env, and add .env to .gitignore in the same step so neither value reaches GitHub. Add a typed Supabase client under src/lib, then write a short CLAUDE.md describing the stack and fixing the vocabulary for a ticketing platform (organisation, event, performance, ticket type, allocation, order, ticket, scan) and recording two standing rules: the remaining count for a ticket type is derived from its allocation and what has been sold rather than kept as an editable number, and a ticket may be admitted exactly once, checked on the server rather than on the scanning device.

   Both rules belong in CLAUDE.md rather than in this one message. They are the assumptions every later step depends on, and a remaining-count column that anything can write is exactly the shortcut an assistant reaches for when a storefront needs to load faster.

2. 02

   Model the event, then put a shop in front of it

   Organisations, events, dates, and ticket types, with a public storefront over them. Nothing here takes money yet, which makes it the cheap place to find out your ticket types do not match how you actually sell.

   PromptModel the events and build the storefrontCopy

   Write the data model as Supabase migrations, with no authentication yet. Organisations each own venues and events. Events carry a title, description, image, status, and the organisation they belong to. Performances, since one event can run on several dates, each carry a start time, a door time, and a capacity. Ticket types belong to a performance, each with a name, a price, an allocation, a count sold, and a maximum per order. Seed two organisations with three events between them, including one with early-bird and standard tiers at different prices. Then build the public storefront over it: a browse page with search and a date filter, and an event page showing the dates, the ticket types with their prices, what is left, and a quantity picker that respects the per-order maximum. No accounts and no checkout yet. I want to click through and tell you where the selling model is wrong before anything depends on it.

   Seed a two-tier event on purpose. Early-bird and standard sharing one date is where most ticket models first disagree with themselves, and finding that now costs a prompt rather than a migration against real orders.

3. 03

   Make the last ticket impossible to sell twice

   The single hardest thing in this build, and the one that is invisible until an on-sale goes well. Reserve and sell in one operation, then prove it under two orders arriving at once.

   PromptBuild the checkout that cannot oversellCopy

   Build the order path. Orders belong to a performance, carry 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 to a ticket type. The important part is how stock moves: write a Postgres function that takes a ticket type and a quantity, locks that row, checks the allocation against what is already sold, and either creates the order and its tickets and increases the sold count in the same transaction or fails with a clear reason, never a read of the remaining count followed by a separate write. Expose it through a Supabase edge function so the browser never writes the count itself. Give a pending order a hold window, and add a job that expires unpaid holds and returns their stock. Then prove it: run two orders for the last two tickets at the same moment and show me that exactly one succeeds and the count lands correctly.

   Insist on the concurrent proof rather than a description of the locking. Anything reading and then writing looks perfect on your laptop, where you are the only buyer. The first time it is wrong is the first time an event sells well, which is also the worst time to find out.

4. 04

   Add the three roles, then scope every row to an organisation

   Now there is something worth protecting. Three kinds of account share this database, and the middle one gets handed to whoever is working the door on the night.

   PromptAdd auth, roles, and access rulesCopy

   Add Supabase Auth with email and password: sign-up, login, logout, a persisted session, and a useUser hook. Add an app_role enum of 'buyer', 'staff', and 'admin' with a user_roles table, kept out of the user's own metadata so nobody can promote themselves, a SECURITY DEFINER has_role function, and a membership table linking accounts to organisations with a has_org_access function. Then enable row-level security across organisations, events, performances, ticket types, orders, tickets, and scans, with rules that check role and organisation together: a buyer reaches their own orders and tickets and nothing else, staff reach the events of their own organisation and may sell and scan but not change prices or read takings, and an admin reaches everything in their own organisation only. Put explicit WITH CHECK clauses on every insert and update. Then sign in as a buyer from one organisation’s event and show me that another buyer’s orders and another organisation’s events both come back empty.

   Ask for the proof as a signed-in query, not a description of the policy. The staff role is the one to check hardest: it goes to the most people, often casual ones on the night, and it is the role most likely to have been given a power nobody meant to grant.

5. 05

   Build the door: QR tickets, the scanner, and the counter

   The part your staff actually use, on a phone, standing up, with a queue behind them. Build it before you polish anything, because it is the part that has to be rehearsed rather than reviewed.

   PromptBuild the doorCopy

   Three things, in one go. First, ticket issue: give every ticket an unguessable code that cannot be derived from the one next to it, render it as a QR on a "My tickets" page the buyer can reach any time, and let them download it. Second, the scanner: a staff-only screen using the device camera that reads a code, calls a server-side edge function to validate it, and returns a result readable at arm’s length: valid and admitted, already used with the time and device that used it, wrong event, or refunded. The redemption has to happen on the server and has to be safe against the same code arriving twice at once. Add an offline queue: hold the valid codes for the event on the device, admit against them when the network drops, queue each scan, and reconcile when it returns, flagging anything that turns out to have been admitted twice. Third, a box office till for walk-ups that sells against the same stock as the website, including a cash option. Then walk me through scanning one ticket twice and show me what the second scan says.

   The offline behaviour needs a decision from you rather than a default. Admitting a genuine attendee and catching duplicates on reconciliation keeps the queue moving. Refusing anything unverified keeps the count exact. Tell it which you want, because whichever it picks unprompted will be the one you discover on the night.

6. 06
   Destination

   Refunds, reports, and a dress rehearsal

   The back office, and then the part most builds skip: run a whole event end to end, on a phone, before a real one.

   PromptAdd the back office and rehearseCopy

   Finish the back office. Refunds and exchanges as server-side functions: a refund cancels the tickets, returns their stock to 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 (events, orders, payments, venues) and reports: what sold by ticket type, what came in, how many were scanned in against how many were sold, and when people arrived across the evening, each exportable as CSV. Then run the app and take me through a whole event: publish it, buy two tickets as a buyer, sell one more at the box office, scan all three on a phone, try the first one a second time, refund one and confirm the stock went back, and check that the sales and attendance reports agree with what actually happened, then fix whatever breaks on the way.

   Do the rehearsal on an actual phone rather than in a desktop browser window. The camera permission, the screen brightness, and how long a scan takes with one bar of signal are all things that behave differently on the device your staff will hold.

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.

Each prompt above picks the model that fits the job. As a rule of thumb, that is Haiku for high volume, Sonnet for everyday writing, and Opus for deeper reasoning. Model names move faster than this page does, so check the current list in the Claude docs (linked in the references below) before you build. Send every one of these prompts through that same ai function, so one key and one set of rules governs all of them.