How to build an event ticketing system with OpenAI Codex

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 learn.chatgpt.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 Codex runs the commands.

1. 01

   AGENTS.md comes before the scaffold, not after it

   Every task Codex starts begins by reading that file. Writing it first means the two constraints this build turns on are already loaded before a single line exists to violate them.

   PromptSet up the projectCopy

   Start by writing an AGENTS.md at the project root: the stack is React 18, Vite, TypeScript, Tailwind, and the Supabase JS client, and this project is an event ticketing platform. Fix the vocabulary (organisation, event, performance, ticket type, allocation, order, ticket, scan) and record two standing constraints: what remains of a ticket type is always derived from its allocation and what has sold, never held as a figure the client can write, and a ticket is redeemable exactly once with that check performed on the server rather than on the scanning device. You load that file automatically at the start of every later task. Then scaffold the project: a typed Supabase client under src/lib reading VITE_SUPABASE_URL and the publishable key (the sb_publishable_… key that replaced the older anon key) from .env, with .env confirmed present in .gitignore. Start the dev server once to prove it boots.

   The derived-count rule is the one worth writing down. Caching the remaining number is a reasonable-sounding optimisation for any assistant to propose later, and it is how a storefront and a gate start disagreeing about whether an event is sold out.

2. 02

   Give the schema and the storefront one task each

   Two tasks that are cheap to get wrong and cheap to redo, since nothing depends on them yet. The point of doing them together is to click the storefront and find out whether your ticket types match how you actually sell.

   PromptModel the events and build the storefrontCopy

   Two tasks. First, the data model as Supabase migrations, with no authentication in this task. Organisations own venues and events. Events carry a title, description, image, status, and their organisation. Performances, because one event can run several times, each carry a start time, a door time, and a capacity. Ticket types sit under a performance with a name, a price, an allocation, a sold count, and a per-order maximum. Show me the SQL before you run it, then seed two organisations with three events between them, one of which has early-bird and standard tiers on the same date. Second task, the public storefront over that: browse with search and a date filter, and an event page listing dates, ticket types, prices, what remains, and a quantity picker honouring the per-order maximum. Nothing signs in and nothing sells yet.

   Seed the two-tier event deliberately. One date carrying two prices is the first place a ticket model contradicts itself, and it is much cheaper to notice now than in a migration against live orders.

3. 03

   Give the oversell problem its own task, and read that diff

   The largest piece of genuinely tricky logic in the build. Keep it in one task, ask for the SQL before it runs, and test the collision rather than the happy path.

   PromptBuild the checkout that cannot oversellCopy

   One task, the order path. 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. The part I want you to be careful about is stock: write a Postgres function that takes a ticket type and a quantity, takes a row lock, compares the allocation against the sold count, and then either creates the order, creates its tickets, and increments the sold count within one transaction, or fails with a reason, never a read followed by a later write. Call it from a Supabase edge function so no browser ever updates the count. Give pending orders a hold window and add a job that expires unpaid ones and releases their stock. Show me the SQL before it runs. Then demonstrate two simultaneous orders for the last two tickets and print what each returned and what the counts are afterwards.

   This is the task to spend a round trip on. Asking for the SQL first is cheap. Discovering during a sold-out on-sale that the check and the write were two statements is not.

4. 04

   Narrow Codex’s permissions, then add the roles

   Authentication and the rules guarding your buyers’ names and email addresses, in one task. Tighten what Codex is allowed to do for this one rather than running it under whatever you use for ordinary edits.

   PromptAdd auth, roles, and access rulesCopy

   Narrow your permissions for this task before starting it, because everything here touches authentication. Wire in Supabase Auth for 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 off the account itself, since anything stored there is editable by its owner, plus a SECURITY DEFINER has_role function, and a membership table tying accounts to organisations with a has_org_access helper. Then row-level security over organisations, events, performances, ticket types, orders, tickets, and scans, where every rule checks role and organisation together: a buyer sees only their own orders and tickets, staff see their own organisation’s events and may sell and scan without touching prices or takings, and an admin is scoped to their own organisation and no further. Explicit WITH CHECK on every insert and update. Show me the policies as SQL before they run, then walk me through querying as a buyer to prove another buyer’s orders and another organisation’s events both come back empty.

   Three roles across two dimensions means more policies than tables, and the one nobody wrote is the one that leaks. Ask for the list of tables and roles it actually covered and check it against your own schema rather than assuming the set was complete.

5. 05

   The door, in one task: tickets, scanner, and till

   Three features share one constraint: they all run on a phone in a doorway. That is why they belong in one task and get tested the same way.

   PromptBuild the doorCopy

   One task covering the whole door. Ticket issue first: every ticket gets an unguessable code that cannot be inferred from its neighbours, rendered as a QR on a "My tickets" page the buyer can return to, with a download. Then the scanner: a staff-only camera screen that reads a code, calls a server-side edge function to validate and redeem it, and shows a result legible at arm’s length: admitted, already used with the time and device that used it, wrong event, or refunded. Redemption happens on the server and must be safe against the same code arriving twice at once. Then the offline path: cache the event’s valid codes on the device, admit against that cache when the network is gone, queue every scan, reconcile on reconnect, and flag anything that turns out to have been admitted twice. Finally a box office till selling walk-ups against the same stock as the site, cash included. Flag in the diff anywhere you put a decision on the device that belongs on the server.

   The offline rule is yours to choose, not Codex’s to infer. Admit-and-reconcile keeps a queue moving and accepts that a duplicate may get through. Refuse-if-unverified keeps the count exact and stops the queue. Say which, or you will find out on the night.

6. 06
   Destination

   Hand the reports to a cloud run, then rehearse it yourself

   Refunds, exchanges, and reporting are well-specified and self-contained, a reasonable hand-off while you do something else. The rehearsal at the end is not, and it is the part that finds what a diff cannot.

   PromptAdd the back office and rehearseCopy

   Two pieces, both self-contained enough to run unattended. First, refunds and exchanges as server-side functions: a refund cancels its tickets, returns the stock to the allocation, and records who did it and why. An exchange voids the old tickets, issues replacements carrying new codes, and settles the difference. Second, the admin panel over events, orders, payments, and venues, plus reports (sales by ticket type, revenue, scanned against sold, and arrival times across the evening), each exportable as CSV. When both are merged, run the app and take it end to end yourself: publish an event, buy two tickets, sell a third at the box office, scan all three on a phone, present the first one again, refund one and confirm its stock returned, and check the sales and attendance reports against what you actually did, then fix whatever does not hold up.

   If you hand the first half to a cloud run, read the refund diff before merging it. Returning stock to the allocation is one line in a function that otherwise looks finished, and its absence is invisible until a refunded event stays sold out.

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 should pick whichever model tier fits the job: a fast, lower-cost model for high-volume work, and a stronger reasoning model for anything that weighs tradeoffs against each other. Codex’s model names change faster than this page does, so check OpenAI’s current model line-up (linked in the references below) before you build, rather than copying a name you saw once. Keep all of it behind that same ai function, so one key and one rule set covers every feature you add.