Start a project
by demand
pricing
real-time
updates
scheduled
auction lifecycle

Promoters get a price the room actually sets instead of one guessed weeks in advance, and fans get a result they can trust was computed the same way for everyone — without either side needing a person to run the auction by hand.

// the problem

The problem

A fixed price for a general-admission ticket is a guess made weeks before the event. Guess low and a sold-out show leaves money on the table; guess high and seats stay empty while the room fills at the door. An auction fixes the pricing problem by letting demand set the price instead — but the moment a ticket's price can move in real time, every fan watching it has to see the same number at the same instant, or the auction stops being fair.

  • Bids must never be lost or double-counted, no matter how many arrive at once
  • Every fan watching a selling period must see the same current price at the same time
  • Auctions must open and close on schedule, with no human starting or stopping one
  • The winning outcome must be defensible to both the fans who lost and the promoter who gets paid

// engineering

How we built it

One authenticated price, pushed to everyone watching

Bids and price changes go out over authenticated WebSocket sessions, so a fan watching a selling period sees the same current price and the same outbid notice as everyone else, at the same time, instead of polling a page that might already be stale.

Auctions run on a schedule, not on a click

Each selling period has a start and an end, and scheduled jobs open and close bidding when those times arrive. Nobody presses start or stop on an auction — the schedule is the operator, which is what lets an auction run unattended for events with no staff watching the clock.

A deterministic step decides who wins

When a selling period closes, a winner-determination step resolves the clearing price and allocates tickets from the full bid history in one pass, the same way every time, so the result is a calculation the promoter can point to rather than a judgment call made under pressure.

Card data never touches the platform

Payment is authorized through the gateway's client-token flow, so a winning bidder's card details go straight to the payment gateway and the platform only ever holds a token — the same reasoning against holding raw card data that shapes every payment integration we build.

// result

Outcome

Organizations and promoters list venues built from data-driven SVG seat maps, run events with either timed auctions or conventional fixed-price sales on the same schema, and watch bidding open and close on its own schedule. Every bid is recorded with full history, every watcher sees the same price as it moves, and every closed period resolves to a winner and an order without anyone touching a control.

Two sales models share one schema: a timed auction where bids decide the price, and a conventional fixed-price sale for events that don’t need one. Both post through the same real-time layer and the same scheduled open and close.

Real-time event push · Scheduled job orchestration · Relational database · Payment gateway integration · Data-driven SVG rendering

30 minutes with a senior engineer.

Tell us what you're building. You'll leave with an honest opinion, even if it's "you don't need us."

Reference calls with past clients are available under NDA during evaluation.