Event ticketing platform development and event management software that does not oversell

What we build

Ticketing looks like e-commerce with dates attached. It is harder: stock is fixed and perishable, demand arrives all at once when tickets go on sale, the same seat cannot be sold twice, and the money belongs to someone else until the event happens. We build platforms where those rules are enforced by the system rather than by staff fixing oversold events the night before.

Features by user type

Inventory holds and oversell prevention

The core rule: a ticket is either available, held for one buyer for a short time, or sold, and moving between those states is atomic. Common designs:

• Holds with expiry: selecting tickets creates a hold for a few minutes, enforced in the database with a conditional update on remaining capacity (or a row lock per seat), never by reading the count in application code and writing it back.
• Payment after hold: the payment is only attempted while the hold is valid, with an idempotency key per checkout attempt, so a double tap or a retried request never charges twice.
• Expiry sweeps: expired holds return to stock by a scheduled job and by a check at read time, so a crashed worker does not leave seats stuck.
• Reserved seating: each seat is its own inventory row with section, row, number, price level and accessibility flags; general admission is a counter per ticket type.

On-sale queues and traffic spikes

A popular on-sale sends more visitors in a minute than a normal week. A virtual waiting room such as Cloudflare Waiting Room admits visitors at a rate the checkout can handle and shows everyone else their place. Behind it, event pages are cached at the edge, inventory reads come from a fast store, and only holds and payments touch the primary database. We load-test the full purchase path at several times the expected peak before any big on-sale, and add bot controls (rate limits, challenge pages, purchase limits per account and card) because resale bots target exactly these moments.

QR check-in, refunds and transfers

• QR tickets: each code is a signed token that the scanner app verifies offline, with the scan list downloaded before doors open and synced back when the connection returns. Duplicate scans on two devices are reconciled and flagged.
• Rotating codes: for high-demand events the QR code refreshes in the app every few seconds, which makes screenshots useless for resale.
• Transfers: the ticket is reissued to the new holder's account and the old code is invalidated, with limits and an audit trail set by the organiser.
• Refunds: policy per event (full, partial, credit, none), automatic refunds when an event is cancelled, and fee handling that matches what the attendee was told at checkout.

Fee display: the FTC rule for live-event tickets

The FTC's Rule on Unfair or Deceptive Fees (16 CFR Part 464) has applied since 12 May 2025 to any business that offers, displays or advertises live-event tickets in the US, including resellers and third-party platforms. According to the FTC's FAQ (checked October 2026):

• Any advertised price must come with the total price, including all mandatory fees the business knows and can calculate, shown more prominently than other pricing information.
• Taxes, government charges and shipping can be left out of the upfront total but must be disclosed before the customer is asked to pay.
• Optional add-ons such as VIP upgrades can be excluded from the total, but their nature, purpose and amount must be disclosed before payment.
• The final amount, with taxes, shipping and add-ons, must be shown before payment and be at least as prominent as the total price.

We build this into the pricing service: every price shown anywhere (listing, search result, seat map, email) is computed by one function that returns the total with mandatory fees, so no page can show a lower number by accident. Some US states have their own ticket pricing laws; we confirm the list with your counsel.

Organiser payouts and tax by jurisdiction

On a marketplace the money belongs to the organiser, minus your fee, but the event has not happened yet. Stripe Connect handles organiser onboarding and KYC; the decisions are when to pay out (after the event, or before with a reserve), how much to hold back for refunds and chargebacks, and who carries the risk when an event is cancelled. For tax, admissions are taxed differently by country, state and sometimes city, and a business selling across borders needs a tax path per country. Stripe Tax or a similar service calculates the rates; the platform still has to know where each event takes place and where the seller has nexus.

Technology we use

How a project runs

1. Discovery (one to two weeks, $3k to $8k): platform type, ticket formats, seating, markets and tax, payout policy, fee display and the systems you are replacing.
2. Checkout and inventory first: holds, payments, order writes and compensation, with load tests before any other feature is finished.
3. Organiser tools, check-in and refunds in two-week sprints, with demos to your operations team.
4. For rebuilds: sync services so the new and old systems run side by side, then migrate one slice (a market, an event type) at a time.
5. Launch with a rehearsed on-sale, then support on a retainer of $1.5k to $8k per month.

What a ticketing platform costs

Our published band for a full product is $50k to $150k+; a rebuild of an existing platform alongside the legacy system sits at the upper end because of the sync and migration work. Open the ticketing preset in the calculator to change the scope, or read the Eventbrite cost breakdown and our ticketing platform architecture post.

Case study: the Paint Nite platform rebuild

Paint Nite runs ticketed live events and experiences across the US and Canada. Five of our engineers, working alongside a client-side technical lead, designed the database architecture from November 2025 and built the new platform from March to June 2026: a NestJS and Next.js replacement for booking, checkout and operations.

• Eight independent NestJS services behind a single GraphQL gateway, communicating only through a RabbitMQ message queue, with three front-end apps.
• Checkout rebuilt as a six-stage pipeline: quote, tax, tender, persist, emit, effects. The order is written in one atomic transaction, payments are idempotent, side effects are queued and retryable, and failures trigger explicit compensation.
• Separate Stripe accounts, keys and webhook secrets for the US and Canada, with a Canadian tax path and per-state nexus rules.
• Versioned OpenSearch indexes behind aliases, with dual-write during rebuilds and resumable reindex jobs, so search schema changes that used to need production downtime now ship with none.
• Dedicated sync services that keep the new platform and the legacy one aligned, so features migrate in slices instead of in one risky cut-over.
• 754 automated test files run on every pull request; 168 GraphQL operations and 188 internal service handlers delivered, with 53 tracked migrations.

If you are replacing an old ticketing system rather than starting fresh, our legacy modernization page explains the slice-by-slice approach. Related marketplace work is in Seek My Service, and the events hub is at events and ticketing.