Event Ticketing App Development Cost: Built for Ninety Seconds a Year

Most software is sized for its average load. A ticketing platform is sized for ninety seconds, and the rest of the year it is nearly idle. Everything expensive about building one follows from that sentence.

When tickets go on sale, a month of demand arrives inside a minute. The system has to hold a consistent view of a finite, numbered inventory while tens of thousands of people try to claim the same seats, take payment from the ones who succeed, and tell everyone else something true. Get it right and nobody notices. Get it wrong and you have either sold the same seat twice, which is a refund and a reputation, or you have gone down during the only moment that mattered.

This is why ticketing quotes vary so wildly and why the cheap ones are cheap. A booking system that works at ten requests a second is a well-understood piece of work. The same system at ten thousand is a different product with different components, and the difference is not a bigger server.

Two regulatory facts now sit inside the architecture rather than beside it, and neither belongs to one country. All-in pricing, meaning the total including every mandatory fee shown wherever a price is shown, is law in the United States, the United Kingdom and India, arrived at separately and within two years of each other. And the statutes written to stop ticket bots share a drafting choice: they bite only where the seller set a purchase limit, so they protect you exactly to the extent you built limits worth circumventing.

Three questions set the price. Is seating reserved or general admission? Does the product sell its own events or host other people's? And how many surfaces in the product display a price, now that each one has to display a total? Everything else is ordinary work.

Reserved seating costs several times what general admission costs

General admission is a counter. You have 2,000 tickets, you decrement, you stop at zero, and brief oversell is recoverable with an apology and a refund.

Reserved seating is an inventory of uniquely identified objects that cannot be substituted. Seat J14 is not interchangeable with seat J15 to the person buying it. That changes the problem from arithmetic to allocation, and it brings a chain of things with it: a seat map per venue configuration, rendering that map interactively on a phone while thousands of seats change state, holds that expire, and adjacency logic so a family of four is not offered four separated singles.

Seat maps are per configuration, not per venue. The same arena is a different map for an end-stage concert, a theatre-in-the-round and a basketball game. Somebody has to produce and maintain those, which is an operational role, and the tooling for it is a real part of the build that founders rarely picture.

Holds are where correctness is won or lost. When a buyer selects seats, those seats must become unavailable to everyone else immediately, and must return to the pool if the buyer abandons. Too short a hold and people lose seats while entering card details. Too long and you strangle inventory during the only minute that matters. Holds must survive a server dying mid-transaction, which is the case that distinguishes a system that works from one that works on a good day.

If general admission is acceptable for your events, take it. It is the single largest cost reduction available on this product and it is a business decision, not a technical one.

The onsale is a queue problem, not a scaling problem

The instinct is to autoscale. It does not work, for a reason of timing rather than capacity: the spike arrives faster than instances start. By the time new capacity is ready the event has been decided, usually badly.

The working pattern is a virtual waiting room in front of everything else. Arrivals are admitted to the purchase flow at a rate the inventory system can actually serve, and everyone else waits in a queue that tells them their position. The queue is a small, cheap, independently scalable component whose only job is to be the thing that absorbs the flood.

This is as much a fairness mechanism as a technical one. A queue with a visible position converts an experience people describe as broken into one they describe as busy. The same wait, differently framed, with a dramatically different support load.

Pre-generate everything that can be pre-generated. Seat maps, event metadata and pricing tables should be computed and cached before the onsale, not derived under load. The only thing that should be doing real work during those ninety seconds is the allocation of seats and the taking of money.

Test it properly or do not claim it. Load testing at realistic concurrency is a distinct piece of work with its own cost, and it is the one thing that separates a system you believe will hold from one you know will. Any quote that includes high-concurrency onsale handling without a load-testing line is quoting you a hope.

The all-in pricing rule changed where fees get calculated

Three large markets now require the same thing of a ticket price, and they got there independently. In the United States, the FTC's Rule on Unfair or Deceptive Fees, codified at 16 CFR Part 464 and effective 12 May 2025, makes it unlawful to advertise or display a price for a live-event ticket without clearly disclosing the total including every mandatory fee, and it reaches primary platforms, resellers, promoters and third-party marketplaces alike. In the United Kingdom, the drip-pricing provisions of the Digital Markets, Competition and Consumers Act 2024 have applied since 6 April 2025 and require the total price in any invitation to purchase. In India, the CCPA's Guidelines for Prevention and Regulation of Dark Patterns, notified 30 November 2023, name drip pricing and basket sneaking as prohibited practices outright.

Most people read that as a copy change. It is an architecture change. If the total has to appear wherever a price appears, your fee calculation has to run at browse time, on a listing page, for every ticket type on display, at onsale concurrency. Platforms that computed fees at checkout had a cheap calculation on a low-traffic page. Moving it to the highest-traffic page in the product is a different performance problem.

Fees are rarely a flat percentage. They vary by ticket type, payment method, delivery method and venue agreement, and some are capped. A rule engine that was acceptable running once per transaction may not be acceptable running fifty times per page view under load, which usually means pre-computing displayed totals per ticket type and caching them with the event.

Enforcement has already landed on a ticketing platform, and the finding was about where the number appeared. The UK's Competition and Markets Authority fined StubHub UK £889,200 and ordered more than £590,000 refunded to 51,350 customers, about £10 a transaction, for failing to show the total price up front between April and December 2025. The penalty was reduced by 40% because the company admitted the breach and settled. Read the decision as a product specification rather than a legal risk: a platform that can only produce a total at checkout gets rebuilt, not reconfigured.

Selling your own events or hosting other people's doubles the build

A platform that sells tickets to events you run is one product. A platform that lets other promoters create and sell their own events is a different one wearing the same clothes, and the gap between them is routinely underestimated at quoting time.

Multi-tenancy brings a second complete application. Every promoter needs onboarding and identity verification, event creation with your approval workflow, their own pricing and fee configuration, their own reporting, and payouts. That organiser-facing side is often larger than the buyer-facing side, and it is invisible in a feature list written from the ticket buyer's point of view.

Payouts are the part that turns you into a financial operation. Paying many promoters, on different schedules, net of fees and refunds, with statements they will query, is the same statements-and-payouts problem that rights platforms solve, and it carries the same requirement to be correct rather than approximately correct. Our media software development page puts statements and payouts at 200 hours in a comparable platform, and that figure is for a system where the counterparties are known and contracted in advance rather than self-serve.

Fee configuration per promoter interacts badly with all-in pricing. If each promoter sets their own service fee, and the total must be displayed at browse time, then your cached price totals are per promoter per ticket type, and a promoter changing their fee invalidates a cache during an onsale somebody else is running.

Trust and abuse become your problem. Self-serve event creation attracts fraudulent events that collect money for things that will not happen, and you are the one holding the funds and facing the chargebacks. Identity verification on promoters and a hold on first payouts are not optional in a self-serve model, and they are a meaningful piece of work.

If you only ever sell your own events, say so clearly at the start. It is the second-largest cost reduction available on this product after choosing general admission.

Discovery is where ticketing platforms actually compete

Everything above is about not failing. None of it is a reason anyone chooses your platform, and founders consistently fund the hard parts and starve the part that decides whether the hard parts ever get used.

Buyers arrive knowing what they want or not knowing at all, and those are different products. Someone searching for a named artist needs the fastest possible path from search to checkout. Someone browsing what is on this weekend needs filtering by date, location, price and category, and genuinely useful results. Serving only the first is why many ticketing products feel like database front ends.

Location and date filtering are harder than they look at scale, because the interesting query is "near me, soon, that I might like, with tickets still available", and availability changes constantly. Caching that result set is exactly what you want for performance and exactly what produces listings for sold-out events.

Notifications are the highest-return feature on the product and the most often deferred. An onsale alert for an artist a user follows converts far better than any homepage, and it is the mechanism that brings people back between purchases, which on a product with a long gap between transactions is the whole retention problem.

Build the follow-and-notify loop early even if discovery itself is thin. A simple list of followed artists and venues with a reliable onsale alert outperforms an elaborate browse experience with no reason to return.

Bots, and why the law only helps if you built the controls

Two jurisdictions legislated against ticket bots and both made the same drafting choice, which is the one that decides your backlog. The US Better Online Ticket Sales Act makes it unlawful to circumvent the access control measures a seller uses to enforce ticket purchasing limits, and to resell tickets obtained that way; it applies to venues seating more than 200 and is enforced by the FTC and state attorneys general. The UK's Breaching of Limits on Ticket Sales Regulations 2018, in force since 5 July 2018, make it a summary criminal offence to use software to obtain tickets in excess of a sales limit with a view to financial gain. The instrument caps the fine at £50,000 in Scotland and states no maximum for England and Wales.

Read the mechanism carefully, because it determines what you have to build. The US Act prohibits circumventing access controls. The UK regulations go further and say it outright: they apply only where, in the words of regulation 2(c), “the offer is subject to conditions that limit the number of tickets a purchaser may buy”. No limit, nothing to exceed, no offence. If you have set no purchase limits, neither law gives you anything at all. The legal protection is downstream of the engineering, in both countries, by drafting.

Nor can you sit outside it by incorporating elsewhere. Regulation 4 of the UK instrument applies whether the offer is made, or anything is done to obtain the tickets, inside the UK or outside it. If the event is in the UK, the rules reach your platform wherever it runs.

Enforcement is real but not a deterrent you can rely on. The first cases, brought in January 2021 against three New York-area brokers, carried civil penalties of $16 million, $11.2 million and $4.4 million, of which roughly $3.7 million was actually paid because the defendants could not pay more. A later settlement with a Georgia broker imposed $10.7 million with all but $300,000 suspended; that broker had used 75 accounts to obtain 277 tickets for a single Metallica concert.

So build the controls, and expect them to be attacked. Per-account and per-payment-instrument purchase limits, velocity checks, device and behavioural signals, and a review path for the accounts that trip them. The 75-accounts-for-277-tickets pattern is the one to design against: not one bot buying a thousand tickets, but a hundred plausible-looking accounts buying four each.

Accept that you will get it wrong in both directions. Blocking real buyers at onsale is a worse customer outcome than letting a broker through, so there must be a human path for a wrongly blocked customer that resolves in minutes rather than days.

The gate is an offline problem

Validation at the door is where ticketing platforms built by web teams fall over, because the assumption that there is a network does not survive a venue.

Connectivity at the gate is unreliable precisely when it matters. Twenty thousand people arriving in an hour with their phones on saturates the same cellular capacity your scanners want, and many venues are concrete boxes.

So scanners hold a local copy of valid tickets and validate offline, then reconcile. Which immediately creates the problem the whole design exists to prevent: two scanners, both offline, can each accept the same ticket. You cannot eliminate that window. You can shrink it, and you decide in advance what happens when reconciliation finds a duplicate, because that decision is a policy about turning people away rather than a technical one.

Rotating codes beat static ones for anything resold or transferred, because a static QR screenshotted and forwarded is indistinguishable from the original at the gate.

Hardware and staffing are part of this cost and are usually omitted. Scanners, their configuration, their charging, and training the people holding them are real line items. A platform that works perfectly and hands a venue an unusable scanning experience has failed at the only point the public sees it.

Money moves differently here, and it is not your money

Ticketing carries a financial structure most founders do not price: you collect money months before an event, for someone else, and you may have to give it back.

Settlement timing is a real obligation. Funds collected at onsale typically belong to the promoter and are remitted after the event, which makes you a custodian of other people's money for months. The regulatory position on that varies by market and is worth a direct question to a payments specialist before launch rather than after.

Chargebacks arrive late and in bulk. A cancelled event generates a wave of disputes at once, long after settlement, and the platform is usually the one facing the card networks. Reserve policy and cancellation handling belong in the plan from the start.

Refunds and exchanges are not the reverse of a purchase. Returning a seat to inventory, reissuing it, handling partial refunds on multi-ticket orders and keeping the fee treatment consistent with what was disclosed at purchase under the all-in rule is a module in its own right.

Payment failure at onsale is its own design problem. A card declining during the ninety seconds means the hold expires and the seats return to a pool that has already been emptied. Decide deliberately whether a failed payment gets a retry window or loses the seats.

What this costs, and what we would build first

Build the inventory and allocation core first, with load testing inside it rather than after it: the measure of done is a test at realistic concurrency that does not oversell. The queue comes second because it protects the core. Gate validation comes third, before the first event rather than the first sale.

Our rate band is published: $40 to $100 an hour by role, blending to $60 to $70 for a mixed team. On this product the allocation and payment path sits at the ceiling and the marketing pages sit at the floor, and the mix matters more than the blended rate.

The inventory and allocation core comes first, with load testing as part of it rather than after it. The measure of done is a test at realistic concurrency that does not oversell, not a working checkout.

The queue comes second, because it is what protects the core and because it is cheap relative to what it prevents.

Gate validation comes third and must be built before the first event, not before the first sale. Teams routinely ship selling and discover scanning three weeks out.

Resale, dynamic pricing, recommendations and loyalty defer cleanly. None of them changes the shape of what is underneath.

We do not quote a fixed total before a discovery that establishes reserved versus general admission, expected peak concurrency and which markets you sell into, because those three answers change the engineering by a multiple. What we will tell you free is that if your events can be general admission, make them general admission.