Custom Event Ticketing Platforms: Where Your Fees and Fan Data Actually Go

Why ticketing software makes or breaks a live events operator

You run four rooms: a 2,800-cap theater, a 1,400-cap club, a 600-cap listening room, and a 350-cap bar with a stage. Call it 300 shows a year. The theater sits on an AXS or Ticketmaster agreement because the national promoter you co-book with insists on it. The club is on Eventbrite. A Sunday matinee series still runs on Etix because someone set it up in 2016 and nobody wants to be the person who breaks it. Your box office manager maintains a Google Sheet that reconciles all three, because none of the three agree on what a ticket even is: one counts comps as sold, one counts them as zero-dollar orders, one hides them entirely.

Here is where the money actually goes. Eventbrite's published US list pricing for the Professional package is 3.7% plus $1.79 per ticket, with payment processing another 2.9% on top. On a $32 face value ticket that is about $2.97 of platform fee before processing touches it. Move 210,000 tickets across your rooms in a year and that is over $620,000 leaving the building. Yes, you can pass it to the fan. That is the trap. The fan's tolerance for the all-in price is fixed at roughly $42 whether you like it or not, so every dollar the platform takes out of that ceiling is a dollar of your own service fee, your own facility fee, your own ticketing revenue that you cannot charge.

Then Thursday night happens. A local hardcore band sells out the club. Your talent buyer wants to email everyone who bought a metal show in the last 18 months to seed the next one. What you can get is a CSV with an email address and an event name. Not the seat. Not whether they scanned in. Not whether they bought two beers or none. Not whether they are the same human as the person who bought under a Gmail alias at the theater. You do not have a database. You have a report.

Problem one: you do not control the fee, and you do not control the checkout

The fee is not a line item you negotiate once. It is a structural position. On a platform deal the vendor sets the fee schedule, the vendor's name is on the receipt, and the vendor's checkout decides whether you can sell a $32 ticket with a $6 parking add-on, a $14 shirt, and a $95 four-show punch pass in one transaction. You cannot. So the shirt sells at merch, the parking sells at the lot, and the punch pass does not exist.

Eventbrite, Etix, and See Tickets cannot fix this because the fee is their business model, not a setting. Even the flexible ones give you a percentage slider inside their fee, never the fee itself.

A custom build inverts it. You go direct to Stripe or Adyen and negotiate interchange-plus at volume instead of paying a marked-up 2.9% plus $0.30. Your fee engine becomes rules you own: a per-order facility fee that scales with room, a waived fee for members, a $2 surcharge on the co-promoted shows where you eat the guarantee, dynamic fees by tier. Your cart holds tickets, parking, merch, food and beverage credit, and a season pass in one payment intent with one refund path. That single change, moving from a marked-up processor to a direct one, typically recovers a meaningful slice of the build cost before any fee strategy is applied.

Problem two: your fan list is a report, and the platform knows it

The lock-in is not contractual, it is architectural. Ticketmaster and AXS deals put their brand on the confirmation email, their cookie on the fan's browser, and their identity record at the center. You get exports. You do not get the graph.

What you need is boring and specific: a person record that dedupes across email, phone, and payment method fingerprint, so the guy who bought as jsmith@gmail in 2023 and j.smith+tix@gmail last Friday is one human. Attached to that person: every order, every seat, every scan timestamp, every no-show, every refund, every bar tab if your point of sale (POS) is Toast or Square, every genre tag from the shows he actually walked into rather than the ones he clicked.

No off-the-shelf platform will build this, because the fan belongs to them. In a custom build the identity service is the spine and everything else writes to it. Then Klaviyo, Salesforce, or your own campaign tool queries it: everyone who scanned into a metal show in the last 18 months, spent over $60 lifetime, and lives within 30 miles. That is a list you can monetize, and it is the asset that survives you switching anything else.

This is where AI does real work. A model over that scan-and-spend history forecasts walk-up volume and no-show rate per show type, so your door staffing and bar par levels stop being guesses. Lapsed-buyer win-back sequences write themselves against real attendance, not email opens. And an after-hours agent on your site handles the private hire and group sales inquiries that currently die in an inbox until Monday, pulling live availability and placing a hold before the lead goes cold.

Problem three: seat maps that cannot model your actual room

Your theater has 14 obstructed-view seats behind a column, ADA positions that must pair with a companion seat and release together at 48 hours out if unsold, a pit that flips between 400 GA standing and 180 cabaret tables of four depending on the show, and a balcony you kill entirely for anything under 900 sold because you cannot staff it.

Try expressing that in Eventbrite's reserved seating. You cannot. So your box office manager runs the pit as a separate event, kills the balcony by manually holding 600 seats one at a time, and tracks the ADA companion pairing in a notebook. That notebook is a lawsuit.

A custom build treats inventory as a state machine, not a picture. Each seat carries a state: available, held, killed, comped, reserved-in-cart, sold, transferred, scanned. Holds carry a reason code and an owner, artist holds versus production kills versus press, and they expire on a schedule you set. ADA seats carry a companion constraint the engine enforces rather than a human remembering. Configurations are versioned per show, so the same room is GA on Friday and cabaret on Saturday without cloning events. You can license seats.io for the rendering and keep the inventory logic yours, which is usually the right call. What you must never do is let a vendor own the state machine.

Problem four: onsale at 10:00:00 is a distributed systems problem

Ninety seconds decides your year. Eleven thousand people hit one endpoint for 2,800 seats. Half of them are bots. If your site holds and the queue is fair, you sold out. If it stalls, the inventory leaks to StubHub and Vivid Seats at three times face and the artist's manager calls your general manager on Monday.

On a platform you rent their queue and their bot posture, and you find out how good it is at 10:00:01. You cannot instrument it, cannot tune it, cannot explain to the fan why they got a spinner.

A custom build means you own the mechanics: a token-based waiting room that admits at a rate your inventory service can absorb, inventory pre-sharded so hot sections do not serialize on a single row lock, idempotency keys on every payment so a double-tap does not double-charge, cart holds with hard expiry, and device plus behavioral signals throttling the scripted buyers. This is also the single most common place a cheap build fails, so it gets load-tested at three times your worst historical peak before the first real onsale, not after it.

Problem five: settlement still runs on a spreadsheet at 1am

After the show your promoter rep sits in the office with the artist's tour manager and a printout. The deal is a $12,000 guarantee versus 85% of net box office after a $9,500 expense pool. Someone is retyping gross out of Eventbrite, subtracting comps by hand, arguing about whether the $4 facility fee sits inside net, and cutting a check at 1am. Do that 300 times a year across four rooms and two co-promoters and you have a full-time reconciliation problem and a recurring relationship dispute.

No ticketing platform settles a versus deal, because settlement is your business logic, not theirs.

A custom build stores the deal memo as structured terms: guarantee, split percentage, expense pool, what counts as net, bonus thresholds. The settlement engine reads live box office and produces the sheet before doors close, with a full audit trail behind every number. AI does the intake here: drop the signed deal memo or contract PDF in and extraction pulls the terms into fields for a human to confirm, instead of your rep keying them at midnight. Co-promoter splits, tax withholding by jurisdiction, and payouts flow into your accounting system rather than a Dropbox folder named final_v3.

What this costs and how long it takes

These are Digital Heroes delivery bands from 2,000+ projects, not market averages. A focused first release, meaning your own checkout, the inventory state machine, seat maps for your real rooms, a scanner app, and the identity spine, is typically $60,000 to $130,000 and ships in 12 to 16 weeks. That is enough to move one or two rooms off platform and start proving the fee math with real numbers. A full platform adding settlement, memberships and season passes, official transfers and resale, multi-promoter tenancy, and deep integrations lands at $150,000 to $400,000 phased across 6 to 12 months.

What pushes you toward the top of the band in this category specifically: reserved seating in a genuinely irregular room, offline-capable native scanner apps on both iOS and Android against hardware you already bought, official transfer and resale, which drags in identity verification and anti-fraud, PCI scope if anyone insists on touching card data instead of tokenizing, multi-entity settlement, tax rules across states or countries, and legacy inventory sync with a Ticketmaster or AXS allocation you cannot fully leave yet. That last one is the quiet budget killer. Scope it explicitly with the vendor in the room, or it eats a phase.

Build versus buy: my position

Stay on the off-the-shelf tool if you are under roughly 40,000 tickets a year, your rooms are general admission, you have one legal entity, no co-promote splits, no season or membership product, and nobody upstream of you is holding your inventory hostage. Eventbrite is genuinely good at that job and you will not beat it on cost. Building at that volume is a vanity project that will consume your operations director for a year.

Build when these show up. Your annual platform fee spend passes about $250,000, meaning the software costs less than one season of fees. Your rooms have inventory rules the platform cannot express and your staff has invented manual workarounds that create legal exposure. You settle against artists or co-promoters and someone retypes numbers after midnight. You want a membership, subscription, or season product the platform will not sell. Or you have concluded that the fan graph is the actual asset of a live events business and you do not own yours.

The strongest signal is the workaround census. Ask your box office manager to list every manual step between an onsale and a settled show. If that list runs longer than fifteen items, the platform is no longer your ticketing system. It is your bottleneck, and you are paying it a percentage of every ticket to be one.

How to choose a developer for a custom ticketing platform

Make them model your weirdest room on a whiteboard before you sign anything. Give them the obstructed seats, the ADA companion pairing, the pit that flips configurations, the artist holds that expire. If they draw a seating chart instead of a state machine with hold reason codes and expiry rules, they think this is a CRUD app. It is not, and they will discover that during your first onsale, which is the worst possible time.

Ask what happens at 10:00:00. The answer should include a waiting room admission strategy, how inventory is sharded so a hot section does not serialize, idempotency on payment intents, cart hold expiry, and a load test plan at multiples of your historical peak. Vague answers here are disqualifying, no matter how good the portfolio looks.

Probe compliance concretely. Which PCI SAQ level does their architecture land you in, and why, and does any card number ever touch your servers, where the correct answer is no. How do they handle the FTC's all-in pricing requirement for live event tickets, the BOTS Act, and WCAG on the accessible seating purchase path, which is both a legal exposure and the thing platforms do worst.

Finally, ask about the exits. Integration track record with Stripe or Adyen, Apple Wallet and Google Wallet passes, your actual scanner hardware, your point of sale, and your accounting stack. Then get code ownership in writing, plus infrastructure in your own cloud accounts under your billing, plus a documented handover. If a developer will not hand you the keys, you have swapped one lock-in for a smaller and worse one.