How to build an event ticketing system with Replit

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 replit.com, checked August 2026.

The first two are all you need to start. Everything here stays inside the one browser tab, the app included once you publish it, and the GitHub copy is the one deliberate exception.

1. 01

   One message: the app, the database, and the ground rules

   Since Postgres is part of the workspace rather than a separate account, asking for it belongs in the first message, next to the two constraints everything after this depends on.

   PromptSet up the project and the databaseCopy

   Set up a React 18 + Vite + TypeScript app with Tailwind and a server, and add a Postgres database to this Repl, the one Replit provisions, not anything outside. Write a short notes file at the project root recording three things. This is an event ticketing platform. The words throughout are organisation, event, performance, ticket type, allocation, order, ticket, and scan. And two standing rules: what remains of a ticket type is always derived from its allocation minus what has sold rather than stored as an editable figure, and a ticket is redeemable exactly once with that check made on the server rather than on the scanning device. Keep the database connection details in Replit's Secrets rather than in the code.

   Write both rules into the notes file rather than only into this message. A stored remaining-count is the shortcut any assistant reaches for when a storefront feels slow, and it is the one that lets a gate and a shop disagree about whether an event has sold out.

2. 02

   Events and storefront, checked at a checkpoint

   The schema and the public side together. Nothing here writes 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

   Design the schema and the server routes over it. 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, since 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 early-bird and standard prices on the same date. Then the public storefront over it: browsing with search and a date filter, and an event page listing the dates, each ticket type with its price and what remains, and a quantity picker honouring the maximum per order. No accounts and no selling in this message.

   Look at the two-tier event in the preview before going further. One date carrying two prices is where a ticket model usually first argues with itself, and a checkpoint here is the cheapest place to start over from.

3. 03

   The sale, in one transaction the Agent writes

   The hardest thing in the build. Ask for the guarantee in those words, and ask to see two orders collide before you accept it.

   PromptBuild the checkout that cannot oversellCopy

   Build the order path. An order records the performance it belongs to, the buyer’s name and email, a state of pending, confirmed, or cancelled, whether it originated online or at the counter, and its total. Each ticket records its order and its ticket type. Everything else here depends on one function, so write it carefully: it locks the ticket type row, measures the allocation against the sold count, and then within a single transaction either lays down the order, its tickets, and the raised count together, or lays down nothing and returns the reason. A read of the remaining count followed by a separate write is exactly the shape to avoid. Nothing but the server may invoke it, so no browser is ever in a position to move that count. Pending orders get a hold window, and a task you also write expires the unpaid ones and returns their stock. Then, in the preview, drive two orders at the last two tickets simultaneously and show me both responses and the resulting counts.

   Checkpoints pay for themselves at this step. Rolling one back offers to bring the database along, which is precisely what you want while every row is a seed you invented, and precisely what deserves a second thought once real orders exist.

4. 04

   Sign-in, three roles, and rows scoped by organisation

   Nothing hands this database an account id on its own, so the Agent builds both ends of the chain: sessions your server issues, and policies that read the identity your server declares.

   PromptAdd sign-in, roles, and access rulesCopy

   Build sign-up, login, logout, and a server-side session on email and password, with one profile row per account. Add a roles table giving each account buyer, staff, or admin (in its own table, never on the account record, since anything there is editable by that user) and a membership table tying accounts to organisations. Then turn on row-level security across organisations, events, performances, ticket types, orders, tickets, and scans: have the server declare the current account, its role, and its organisation as session-local settings at the start of every request, and write the policies to read them: 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. Then show me how to prove, signed in as a buyer, that another buyer’s orders and another organisation’s events both come back empty.

   Because no hosted identity service passes an account id down to Postgres, the only thing that knows who is asking is your own server. Get that declaration working before the policies, or they have nothing to read and quietly let everything through.

5. 05

   The door, on a published URL rather than a preview

   The scanner is the one screen you cannot judge from the workspace. Replit gives you a real address to open on a real phone, which is the whole reason to build the door here rather than last.

   PromptBuild the doorCopy

   Build the whole door. Every ticket carries a code that gives away nothing about any other ticket’s code, shown as a QR on a "My tickets" page the buyer can revisit and save from. On top of that, the scanning screen: staff only, using the device camera, sending each code it reads to a server route that both checks it and marks it spent. The answer has to be readable from a phone at arm’s length, and it has four forms: admitted, already used at a stated time on a stated device, belongs to a different event, or was refunded. That decision is the route’s to make and never the device’s, and two copies of one code arriving together must not both be admitted. Then the offline path: keep the event’s valid codes on the device, judge from them when there is no connection, queue what was scanned, settle it on reconnect, and surface anything that turns out to have been admitted more than once. Then a counter till for walk-ups, drawing on the same stock the site sells and taking cash. Every route here has to declare the session-local account, role, and organisation before it queries anything. Miss that and the step 04 policies let everything through.

   Publish before you test this rather than after. A camera needs a secure address, and the published URL is one, which also means you can hand it to somebody else and have them scan a ticket while you watch what the server did.

6. 06
   Destination

   Refunds, reports, and publishing

   The back office, a full rehearsal, then Publishing, with the hold-expiry task on its own schedule and a careful look at who the app is visible to.

   PromptAdd the back office and publishCopy

   Two things left. Refunding and exchanging are both server routes. Refunding voids that order’s tickets, returns their stock to the allocation, and leaves behind who approved it and on what grounds. Exchanging cancels the tickets the buyer held, issues new ones under new codes, and settles whatever the price difference came to. Then the admin panel across events, orders, payments, and venues, and the reporting: sales by ticket type, money taken, scanned versus sold, and how arrivals spread across the evening, all four as CSV. Then help me run one event from end to end, published through to reported, taking in a counter sale, a scan on a phone, a second attempt at a code already used, and a refund whose stock I can watch come back. When that holds, take me through Publishing: which deployment type suits the app, which suits the task that clears expired holds, and who the app ought to be visible to on day one.

   Ask which deployment type each piece belongs on and expect two different answers. A storefront answering requests and a task that sweeps expired holds on a timer want different shapes, and Replit publishes both from the same workspace.

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 connection, the secret your ticket codes are signed with, and any payment or AI provider key you add later never go into the app or a public repo. If one gets out, treat it as compromised and rotate it the same day.

All four are Replit rather than a third party, so the choice is shape rather than vendor, and this build wants two of them: Autoscale for the app, Scheduled for the hold sweep. Review who the app is visible to before the first release, since Publishing is what sets it, and remember that a published app is what your scanner needs: a camera only opens on a secure address, so the door gets tested on the published URL, on a real phone, never in the workspace preview.

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.

A cheap model is plenty for most of the prompts above. Save Pro’s stronger models for the one or two spots where the extra reasoning actually pays for itself. Add any provider key through Replit’s own Secrets tool rather than hard-coding it, and keep every AI feature behind one server-side function so a single key covers the whole app.