The break-even ticket volume: when building your own ticketing beats Eventbrite's fees

Every ticketing conversation we have starts the same way: an organiser looks at last season's platform fees, multiplies by next season's volume, and asks whether building their own stack would be cheaper. Sometimes the answer is yes and sometimes it is emphatically no, and the difference is a number you can compute. Before the aggregate, the anatomy of one specific replatform: Ontick, a UK events business that moved off Eventbrite onto a fully owned ticketing platform we built and still run.

Anatomy: Ontick, off Eventbrite onto an owned Laravel stack

The brief. Ontick came to us running their events on Eventbrite. The buyer experience was fine and the operational tooling was fine, but the commission Eventbrite took on every ticket was the largest fixed cost on the business. At the volume Ontick was already running, the percentage made a custom platform a clearly positive ROI decision rather than a vanity project. One feature was non-negotiable from day one: tickets had to be purchasable in instalments, with the QR codes released only after the final payment landed. That single requirement set the architectural agenda for everything that followed. The full write-up lives in the Ontick case study; the short version here is what matters for the fee maths.

Stage 1, the platform. Built end-to-end on Laravel: the public booking surface, the organiser back-end, the super-admin back-end, and the REST API the mobile apps would later consume. One framework, one team, one deploy. The multi-organiser model was the most consequential architectural choice: a super admin creates organiser accounts, and each organiser manages their own events, ticket tiers, inventory and sale windows. The data model was designed for that from day one rather than retrofitted, which is where multi-tenant platforms usually accumulate compounding problems later, as our multi-tenant architecture cost study covers in detail. The booking and instalment ledger sits in MySQL.

Stage 2, the instalment engine.Stripe handles the actual capture; the platform stores tokenised payment methods and orchestrates the schedule server-side, calling Stripe when each instalment is due. The single most important business rule is enforced in code, not in policy: a booking can be paid down over months, but the QR ticket is only minted and emailed once the final instalment settles. Every charge carries a Stripe idempotency key derived from the booking id and the instalment index, so a retried request can never double-charge. Failed charges enter a retry schedule with backoff, and a daily reconciliation cron compares the platform's ledger to the Stripe balance transactions, so drift between the two systems is caught within a day rather than at year-end accounting.

Stage 3, the check-in app. Door staff scan tickets with a React Native app built around one design constraint: speed at queue tempo. The app is offline-first; the full attendee list is cached at session start, scanning resolves locally, and the network round-trip to mark the attendee server-side happens in the background. The door operator never waits on the API, which means the queue never waits on the venue Wi-Fi. Bluetooth scanner support and role-scoped logins round it out: a staff member can only check in attendees for events they are assigned to.

Stage 4, the customer app. A second React Native app gives buyers the whole booking experience in their pocket, and its commercial unlock is push messaging. Three flows that previously sat in email now run over push: upsell offers segmented by booking history, heads-up reminders before the next instalment is due, and failed-payment recovery, where a push lands within minutes of an instalment declining with a one-tap path back into the app to retry. Conversion on that channel is materially higher than the equivalent email sequence. The delivery engineering underneath is the same pattern from our push notifications on Expo, FCM and APNs write-up.

Where it stands.The stack is Laravel, Vue and MySQL on the web side with two React Native apps on top. Since launch the platform has processed 230K+ tickets and £2M+ in sales, at an average ticket value a little under £9. The per-ticket commission that drove the original brief now sits at zero; the only per-ticket cost is Stripe's processing fee. The engagement is ongoing: we run the platform day-to-day and own the observability and recovery flows.

Ontick is the existence proof that the replatform can work: the commission line went to zero, the instalment engine sells tickets Eventbrite could not, and the platform has run for years without a payments incident. But an existence proof is not a recommendation. The question this study answers is when the same decision is right for you, because for most organisers, most of the time, it is not, and the honest way to answer it is with the fee data and a break-even formula rather than a sales call. The aggregate.

Methodology: pricing the same ticket on eight platforms

We priced an identical scenario on eight rented ticketing platforms plus a custom baseline: a $20 general-admission ticket, one ticket per order, sold online with a card payment, using each platform's published self-serve pricing as of July 2026. Where a platform separates service fees from payment processing, we summed both; where processing is bundled, we used the bundled figure. We ignored negotiated enterprise rates (if you have the volume to negotiate, you also have the volume where this study says build) and we ignored free-event tiers, since fee economics on free tickets are moot. The custom baseline pays Stripe's standard published rate of 2.9% + $0.30 per successful card charge, per stripe.com/pricing. We use US dollar pricing throughout the dataset because that is the currency the platforms publish; Ontick's own economics are in sterling, where UK card rates are lower still.

Three computed metrics run through the findings: Effective Fee Rate (EFR), Break-Even Ticket Volume (BETV) and Instalment Recovery Rate (IRR), each defined in the metrics section below.

Finding 1: the same $20 ticket costs $0.88 to $3.11 to sell

The spread is 3.5x between the most and least expensive rented options, which is the first practical lesson of the dataset: most organisers agonising over build vs rent have not yet exhausted the cheaper rentals. On Eventbrite's published Flex pricing, the $20 ticket carries about $3.11 in fees, 15.5% of face value. SimpleTix does the same job for $1.19. Moving between rented platforms captures $1.92 of the $2.23 gap to custom, for zero build cost. The remaining $0.31 per ticket is what the custom build actually competes for on fees alone, which is why the honest break-even model has to include everything a custom platform costs, and everything beyond fees it earns.

Two caveats cut in opposite directions. Flat per-ticket components hit cheap tickets hardest: on a $10 ticket, Eventbrite's EFR climbs past 21% while percentage-only components stay flat. And multi-ticket orders amortise order-level processing fees but not per-ticket service fees, so a family of four buying together improves the custom baseline slightly more than it improves most rented platforms.

Finding 2: fee drag compounds brutally with volume

At 5,000 tickets a year, the Eventbrite-to-custom gap is $11,150: real money, but far less than a custom platform costs to build and run, so the correct move at that volume is a cheaper rental, not a build. At 25,000 tickets the gap is $55,750 a year, which starts to look like an engineering budget. At 100,000 tickets the gap is $223,000 a year, and the conversation inverts: the question is no longer whether you can afford to build, it is how you justify continuing to hand a six-figure line item to a platform whose job your team could own. Ontick's 230K+ lifetime tickets sit well past that inversion point, which is why the replatform paid for itself as quickly as it did even at an average ticket value under £9.

Finding 3: flat fees punish cheap tickets, percentages punish dear ones

The $20 basket hides a structural split in how the platforms charge. Reprice the same dataset at $10 and $50 and the league table reshuffles. On a $10 ticket, Eventbrite's flat $1.79 service component drives the all-in fee to roughly $2.45, an EFR of 24.5%, while SimpleTix sits at $0.99 (9.9%) and the custom baseline at $0.59 (5.9%). On a $50 ticket the picture inverts: Eventbrite falls to a 10.2% EFR, and SimpleTix at $1.79 (3.6%) lands within a rounding error of the custom baseline's $1.75 (3.5%). At high ticket values, percentage-light rentals converge on Stripe-only economics; at low ticket values, flat-fee-heavy platforms take a quarter of the face price.

This is why average ticket value belongs in the break-even model as a first-class input rather than a footnote. Ontick's average sits a little under £9, exactly the territory where flat per-ticket fees bite hardest, which made the rented options structurally expensive for that business no matter which one it chose. A conference organiser selling $400 passes reads the same charts and reaches the opposite conclusion: their cheapest rental is already within a point of custom on fees, and their build case has to rest on capabilities, not fee arithmetic. Neither organiser is wrong; they are on opposite ends of the same curve.

The break-even model

The model is deliberately simple enough to run in a spreadsheet cell. A custom platform costs you an annual amount: the build cost amortised over three years plus the annual run cost. It saves you a per-ticket amount: the rented platform's all-in fee minus Stripe's processing fee at your average ticket value. Divide the first by the second and you have the annual ticket volume where the build breaks even. Three build scenarios from our engagement data: a lean web-only platform at $45k with a $9k annual run cost ($24k a year all-in), a mid build with full organiser tooling at $75k and $15k ($40k a year), and a full build with venue check-in and customer mobile apps at $120k and $24k ($64k a year). Against Eventbrite-level fees the saving is $2.23 per $20 ticket; against a 12% platform it is $1.52; against the 8% tier it is $0.72.

Read the corners. Bottom-left is the trap: an organiser on a cheap rental commissioning a full two-app build needs nearly 90,000 tickets a year to win on fees alone, and almost nobody in that seat has them. Top-left is the sleeper: an organiser paying Eventbrite-level fees clears a lean build at 10,800 tickets a year, roughly 900 a month, which is a single mid-sized venue running weekly events. The fee tier you are leaving matters more than the build you are buying, which is also why the first recommendation below is sometimes "change rental" rather than "build".

Two things the pure fee model undercounts, both in favour of building at the margin. First, capability revenue: Ontick's instalment engine is not an Eventbrite feature at any price, and tickets that can be paid down over months sell to buyers who would otherwise not buy at all. Second, the customer relationship: on a rented marketplace the buyer list, the remarketing surface and the checkout experience belong to the platform. Against that, renting buys you distribution and zero maintenance, and those are worth real money too. The model gives you the floor; the strategy question sits on top of it.

How we measure ticketing economics

1. Effective Fee Rate (EFR)

EFR = Total platform + processing fees / Gross ticket sales

The all-in percentage of face value lost to fees. Across our dataset EFR runs from 4.4% (custom, Stripe only) through 6.0% (SimpleTix) to 15.5% (Eventbrite Flex) on a $20 ticket. Compute it from your own settlement reports rather than the pricing page: absorbed fees, refunds and payment-method mix all move the real number.

2. Break-Even Ticket Volume (BETV)

BETV = (Build cost / 3 + Annual run cost) / ((Platform EFR - Custom EFR) x Average ticket value)

The annual ticket volume where owning the stack beats renting it, amortising the build over three years. Chart 3 tabulates it across our three build scenarios. Sensitivity note: BETV falls fast as average ticket value rises, because percentage fees scale with price while Stripe's flat component does not.

3. Instalment Recovery Rate (IRR)

IRR = Declined instalments recovered within the retry window / Total declined instalments

Not the finance textbook IRR. On an instalment platform, declined payments are routine rather than exceptional, and the recovery flow is a revenue feature. Ontick's push-first recovery, a notification within minutes of the decline plus an automated retry schedule with backoff, recovers roughly four in five declined instalments without a human touching the booking; treat that figure as directional, but the design target it implies (IRR above 80%) is the difference between instalments as a growth lever and instalments as a support queue.

The engineering that earns the lower fee rate

The 4.4% EFR is only real if the platform underneath is boring in production, and payments is where custom ticketing builds go wrong. The Ontick instalment engine ships five guarantees: Stripe performs every capture against tokenised payment methods; QR tickets are held until the final instalment settles; every payment touchpoint is idempotent; failed payments recover automatically; and a daily reconciliation cron compares the platform ledger to Stripe's balance transactions so the two systems cannot silently drift. Beyond idempotency keys there are defensive layers: booking-level locks during a payment attempt, and a guard on the webhook side that refuses to mark a booking paid past its total. The full pattern, signature verification through dead-letter queues, is in our Stripe webhooks reference architecture; the piece worth reproducing here is the claim-before-work insert that makes duplicate webhook deliveries harmless.

-- stripe_events claims each webhook delivery exactly once.
-- The PRIMARY KEY on event_id is the lock.
CREATE TABLE stripe_events (
  event_id         VARCHAR(255) NOT NULL PRIMARY KEY,
  event_type       VARCHAR(64)  NOT NULL,
  booking_id       BIGINT UNSIGNED NULL,
  instalment_index TINYINT UNSIGNED NULL,
  payload          JSON NOT NULL,
  received_at      DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP
);

-- Handler, step 1: claim the event before doing any work.
INSERT IGNORE INTO stripe_events
  (event_id, event_type, booking_id, instalment_index, payload)
VALUES
  (:event_id, :event_type, :booking_id, :instalment_index, :payload);

-- ROW_COUNT() = 0 means Stripe has delivered this event before:
-- acknowledge with a 200 and stop. Exactly one state change per
-- event, no matter how many times it arrives.

The outbound side mirrors it: each charge request carries a Stripe idempotency key derived from the booking id and the instalment index, something like booking-4812-instalment-3, so a timeout-and-retry can never produce a second charge for the same instalment. Between the inbound insert and the outbound key, the reconciliation cron becomes a verification step rather than a repair job; in production on Ontick, none of these guarantees has generated a real-world incident to date. This is the layer our Stripe billing integration engagement exists to build, and it is the part of a ticketing platform we would never let a team improvise.

The regulatory hook: all-in pricing changes the fee game

The fee conversation stopped being purely commercial in 2025. The FTC's Rule on Unfair or Deceptive Fees, the Junk Fees Rule, took effect on May 12, 2025, and it names live-event ticketing explicitly: the first price a buyer sees must include all mandatory fees, itemised before payment, with civil penalties up to $51,744 per violation. Then in September 2025 the FTC and seven state attorneys general sued Live Nation and Ticketmaster over ticketing practices, the loudest possible signal that enforcement in this market is not theoretical. JCA's analysis of the rule's implications for live-event ticketing is the best practitioner summary we have read.

The second-order effect matters for the build-vs-rent maths. Drip pricing let high-fee platforms hide the fee until the buyer was committed; all-in pricing puts the full freight in the advertised price, where it suppresses conversion and where your buyers now compare it against competitors' all-in prices. A 15.5% fee you could once bury is now a 15.5% price disadvantage on the first screen. Organisers on owned stacks get the mirror-image benefit: with Stripe processing as the only fee line, the all-in price and the face price are nearly the same number, which is both trivially compliant and quietly persuasive. We do not build platforms to arbitrage regulation, but when the law pushes the market toward honest pricing, the stack with the lowest honest price wins.

What a custom platform costs to run

Build cost gets all the attention, but the run cost is what the amortisation model actually feeds on, and it is the number owners most often underestimate to zero. The band below is what a platform in Ontick's shape costs to keep in production, from our own invoices and infrastructure bills. The single biggest line is the maintenance retainer: dependency bumps, framework upgrades, Stripe API version migrations, app-store resubmissions and the steady trickle of small features that keep a live platform competitive.

Note what is absent: per-ticket cost. Everything in the table is fixed against volume, which is the whole economic point. A rented platform's fees scale linearly with your success; a custom platform's costs are a flat line that ticket volume amortises further with every event. That asymmetry is why BETV is a threshold rather than a trade-off: below it the flat line looms over your fee savings, above it every additional ticket widens the gap in your favour.

Recommendations

Under roughly 10,000 tickets a year: rent, but rent cheaply

No custom build clears break-even at this volume, including ours, and we say so on the event ticketing platform development page itself: Eventbrite is fine for 95% of events. The actionable move is inside the rental market. Shifting the same 5,000 tickets from Eventbrite's 15.5% to SimpleTix, TicketSpice or Ticket Tailor saves $8,000 to $9,600 a year for an afternoon of setup, capturing most of the custom gap with none of the cost. Revisit the maths when volume, instalments or white-label requirements change.

10,000 to 50,000 tickets a year: the break-even band, model it properly

This is where the decision genuinely swings on your specifics: average ticket value, the fee tier you are leaving, and whether you need capabilities the rentals cannot price, instalment payments and white-label multi-organiser operation being the two we see most. Run BETV with your own numbers before any scoping call, ours included. If the model clears, a lean web-first build is the right first phase: the fee savings start the amortisation clock, and the mobile apps can follow once the platform proves itself, exactly the sequence Ontick ran. Two scoping rules from that engagement. First, the payments layer is where the budget should concentrate; it is the difference between the billing engineering being an asset and being the reason you phone us mid-season. Second, treat the door as a launch feature, not a fast-follow: an offline-first check-in path has to exist before your first event on the new platform, because the venue Wi-Fi will fail on the one night it matters most.

Above 50,000 tickets a year: owning the stack is the default

At this volume even the full two-app build clears break-even against every fee tier in Chart 3, and the annual fee drag on a rented platform is a six-figure line item that compounds with growth. The burden of proof flips: the question is what specifically justifies staying rented, and "marketplace discovery" is the only answer we find regularly persuasive. The stack we ship for this shape is the Ontick stack, Laravelunderneath, Vue on the booking surface, MySQL for the ledger, React Native at the door and in the buyer's pocket, because it is the one we have run at 230K+ tickets without the payments layer generating an incident.

Limitations

Fee schedules were captured in July 2026 from public pricing pages and change without notice; treat Chart 1 as a snapshot, not a contract. The $20 single-ticket basket is a simplification: multi-ticket orders, absorbed vs passed-on fees, and cheaper UK and EU card rates all move EFR by tenths of a point in either direction. Build and run cost bands use blended UK and India engineering rates from our own engagements and will not match Bay Area agency quotes. The anatomy is a single engagement, and Ontick's instalment-led model flatters the case for custom; the IRR figure is directional. The model also prices distribution at zero: if a marketplace genuinely fills your events, that is worth real money the spreadsheet does not see.

The decision, compressed

Renting ticketing costs 6% to 15.5% of every ticket forever; owning it costs a fixed annual amount plus 4.4% to Stripe. BETV is the volume where the lines cross: about 10,800 tickets a year for a lean build leaving Eventbrite-level fees, about 88,900 for a full build leaving the cheapest rentals, and your real number sits somewhere between, one spreadsheet cell away. Below it, change rentals and bank most of the saving. Above it, the fee line becomes an engineering budget with a payback date, and the capabilities that come with ownership, instalments, white-label, the customer relationship, are the compounding upside the fee model never captures.

The payments engineering this study leans on, and the architecture decisions underneath it, in the companion research:

The engagements that build and run a platform in this shape: