How to build an event ticketing system with Bolt

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 bolt.new, checked August 2026.

The GitHub step comes before Bolt exists for you at all. Everything after it happens inside the browser tab Bolt opens, with no install.

1. 01

   GitHub first, then import, then set the rules

   The repository has to exist before Bolt does. Once it is imported, spend the first prompt on the rules rather than on features.

   PromptSet up the projectCopy

   This project is an event ticketing platform on React 18, Vite, TypeScript, and Tailwind. Before building any features, write a short notes file at the project root fixing the vocabulary (organisation, event, performance, ticket type, allocation, order, ticket, scan) and recording two standing rules for the whole build: what remains of a ticket type is always derived from its allocation minus what has sold, never stored as a figure a screen can write, and a ticket is redeemable exactly once with that check performed on the server rather than on the scanning device. Then set up the Supabase client to read the URL and publishable key from environment variables, confirm the environment file is gitignored, and start the app so I can see it boot.

   Put both rules in the file rather than only in this prompt. Bolt reloads the project as context each turn, so a rule that lives in the repository keeps arriving with everything else, and a rule that lived only in a message you sent an hour ago does not.

2. 02

   Events and the storefront, in Plan Mode

   Talk the data model through before any code is written, then let it build the whole public side in one pass. This is the cheap half of the build, and the half a live preview genuinely helps with.

   PromptModel the events and build the storefrontCopy

   Use Plan Mode for this one. Talk me through the schema before you write it. 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 and carries a name, a price, an allocation, a sold count, and a maximum per order. Once we agree, write the migrations, seed two organisations with three events between them including one with early-bird and standard prices on the same date, and build the public storefront: browsing with search and a date filter, and an event page showing the dates, each ticket type with price and remaining, and a quantity picker honouring the per-order maximum. No accounts and no checkout yet.

   Plan Mode earns its keep here specifically. A schema is the change that is most expensive to get wrong and cheapest to talk through first, and on a tool billing by tokens, one conversation beats three rewrites.

3. 03

   One prompt for the sale, scoped to the order path

   Clear the context, then point this prompt at the order path alone. It is the hardest logic in the build and the one you least want competing with the storefront for attention.

   PromptBuild the checkout that cannot oversellCopy

   Clear the context from the storefront work first, then work on nothing but the order path. An order needs to know its performance, the buyer’s name and email, whether it is pending, confirmed, or cancelled, whether it came from the website or the counter, and its total. A ticket needs to know its order and its ticket type. Then the piece everything else rests on: a database function that locks the ticket type row, weighs its allocation against the sold count, and in one uninterruptible transaction either records the order, its tickets, and a higher sold count, or records nothing and explains why. What I do not want is a check followed later by a write. Only a server-side function may call it, so the count is never touched from a browser. Add a hold window on pending orders and a job that clears out the expired ones and gives their stock back. To finish, put two orders on the last two tickets at the same instant and report what each one received.

   The live preview will not show you this one, because you are one person clicking one button. Ask for the collision to be run and reported. It is the single place in this build where the thing you can see working is not evidence that it works.

4. 04

   Roles and access rules, with the context cleared first

   A self-contained change that touches every table. Start it clean, both for the token bill and because it is easier to read as one commit later.

   PromptAdd auth, roles, and access rulesCopy

   Clear the context, then do authentication and access rules as one piece of work. Email-and-password sign-up, login, logout, and a persisted session. Three roles (buyer, staff, admin) in their own table rather than on the account record, since anything stored there is editable by its owner, with a security definer function for checking a role and another for checking organisation membership. Then row-level security over organisations, events, performances, ticket types, orders, tickets, and scans, with 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 without touching prices or takings, and an admin is confined to their own organisation. 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.

   Read the commit Bolt makes for this one on GitHub afterwards. Access rules are the change where a summary of what happened is least useful and the actual diff is most worth two minutes.

5. 05

   The door, and why the preview is not enough for it

   Everything else in this build can be judged in the tab. The scanner cannot: it needs a phone, a camera, and preferably a room with poor signal.

   PromptBuild the doorCopy

   Build the whole door. The ticket comes first: give each one a code that reveals nothing about the codes around it, put it on a "My tickets" page as a QR the buyer can open any time and save if they want to. Then the scanning screen: staff only, camera on, one code at a time, each handed to a server-side function that decides and marks it used. Whatever comes back has to be legible from a phone held out at arm’s length: through you go, that was already used at this time on this device, wrong event, or that one was refunded. Never make that decision on the device, and make sure two copies of one code hitting the function together cannot both succeed. Then the case where the network vanishes: hold that event’s valid codes locally, judge from them while offline, stack the scans up, settle them when the connection returns, and raise anything that turns out to have gone through more than once. Finally, a counter till for people who arrive without having bought, drawing on the same stock the site sells from and accepting cash.

   The camera will not open unless the page is served over HTTPS. Bolt’s preview is, so it works there. The thing to check is the URL you eventually publish, and to check it on the phone your staff will be holding rather than on your laptop.

6. 06
   Destination

   Refunds, reports, and publishing before the on-sale

   The back office, a full rehearsal, and a deploy that happens well before you announce anything.

   PromptAdd the back office and rehearseCopy

   Finish the back office. Both refunding and exchanging live in server-side functions. A refund voids the tickets on that order, puts their stock back into the allocation it came out of, and keeps a note of who authorised it and why. An exchange cancels what the buyer was holding, issues replacements under new codes, and settles up whatever the price difference turned out to be. After that, the admin panel spanning events, orders, payments, and venues, and the reporting layer: sales per ticket type, money taken, scanned against sold, and the shape of arrivals through the evening, each one downloadable as CSV. Then take one event all the way through with me (published, sold to online and at the counter, scanned on a phone including a deliberate second attempt at the same code, one order refunded) and show me the reports agreeing with all of it. Then publish, and tell me which environment variables the published build needs that the preview never asked for.

   Ask that last question explicitly. A published build reads its configuration from the host rather than from the file on your machine, and an empty storefront on launch day is almost always this and almost never the code.

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.

Pick a lighter model for the high-volume prompts above and save a stronger one for wherever the reasoning actually matters. That is the same token-budget logic as the rest of this page, applied to the app’s own AI calls instead of the build itself. When Bolt flags a missing secret, add the key through its secrets settings instead of pasting it into the chat, and keep every AI feature behind one server-side function so there’s only one key to manage.