Development Agency
Contact Sign in Get a project quote

Service

Ticketing platform development

For promoters, venues and festival organisers who sell their own tickets and need allocations, timed releases, seated and general admission events, door scanning, refund rules and promoter settlements to run from one system they control rather than a third-party platform that owns the customer and the fees.

Get a project quote See the software package

The problem

What goes wrong today

Where it usually starts

A six-hundred-capacity venue hosts club nights, gigs and seated comedy.

  • Tickets are sold through two external platforms, a local record shop with paper tickets and the venue's own box office, each holding its own count against a capacity the venue manager keeps in her head.
  • The licensed figure she has recorded for the standing layout is six hundred and twenty; the two platforms are set to three hundred each, the shop has fifty and the box office sells walk-ups, so on a sold-out night the door counts seven hundred names across four lists.
  • Early bird tickets are meant to end on a Friday at midday and are switched off by someone remembering to log in.

Where it gets harder

At the door, one steward scans one platform's app, another checks a printed list from the second platform, and the record shop's tickets are torn by hand.

  • A fan who bought on the wrong platform is sent to the wrong queue.
  • Refunds for a cancelled gig take a week because each platform has its own process and the shop needs cash.
  • The promoter who hired the room wants a settlement showing what sold at each tier and what the venue is owed, and it is assembled in a spreadsheet from four exports with the fees mixed into the face value.
  • The venue knows nothing about the people who bought, because the platforms do.

Scope of the service

What the build covers

A custom ticketing build normally covers:

  • Events with one or several sessions
  • Ticket types with allocations and price tiers set by the organiser Such as early bird, general and concession, each with a quantity and a sale window
  • Timed releases that open and close on a schedule And access codes for pre-sales to a mailing list or a fan club
  • Seated events with a seat map and zone capacities Or general admission against a total the organiser records as their licensed figure
  • An order flow with fees shown separately from the face value
  • E-tickets with QR codes delivered by email and in a wallet pass
  • A scanning page For door staff that works on phones and dedicated scanners, marks a ticket used once and shows the live count by entrance
  • Refund and exchange rules that the organiser sets per event With batch refunds on cancellation
  • Promoter accounts Where each promoter sees only their own events and receives a settlement report by tier with fees separated
  • A waiting list For sold-out events that releases returned tickets in order

How discovery works

Discovery follows a sale from on-sale to the door with the venue manager, the box office and a promoter: how allocations are divided today, when tiers change, what the licensed figures are per layout, how the door is staffed, how refunds work and what the settlement must show. Each becomes a named stage in the scope document: set up, on sale, order, e-ticket, check-in, settlement.

Deliberately out of scope

  • The bar till, stock and the venue's accounting, which stay in their own systems and are connected where it earns its place. Resale marketplaces and external ticket agents are scoped as integration opportunities once we have seen what each exposes

When the scope grows

Scoping scenario

A three-day festival with five stages, camping and day tickets, forty thousand attendees, a seated arena session, wristband exchange at four gates and twelve promoters each settling separately needs ticket types that bundle camping with entry, gate-specific scanning with offline fallback, zone capacities on the arena and a settlement per promoter per day. That is a different build from a single room with weekly gigs, and the scope document says so plainly.

Deliverables

What you receive

  • Discovery notes from one sale followed from on-sale to the door, including allocation splits, tier timings and the recorded capacity per layout
  • A written scope document naming each stage from set-up to settlement, with what is out of scope
  • Design of the organiser event set-up, the customer order flow, the e-ticket, the door scanning page and the settlement report on phone and desktop
  • The build, deployed to your hosting or ours
  • Migration of future events, outstanding orders and customer records from current platforms, where their exports allow
  • Training for the box office, door staff, promoters and the venue manager, with a short written guide
  • Handover material and full ownership of the source code and your data

Process

How a project runs

Each stage maps onto the project view in your client panel. Durations are set in your proposal, never on this page.

  1. Onboarding

    Access, contacts and a look at the current platform accounts, the box office process, the door routine and a recent settlement spreadsheet.

    Project stage: Onboarding

  2. Planning

    Discovery with the venue manager, box office and a promoter; ticket types, allocation rules, seat maps, refund rules, scanning approach and settlement format are agreed in the scope document with a milestone plan.

    Project stage: Planning

  3. Design

    Clickable designs of the event set-up, the order flow, the e-ticket and the scanning page, checked on the phones door staff will hold in the dark.

    Project stage: Design

  4. Development

    Built in stages: events, sessions, ticket types and allocations first, then orders, payment and e-tickets, then scanning and check-in, then refunds, exchanges, promoters and settlements.

    Project stage: Development

  5. Client review

    The team runs a test on-sale with a timed tier change, a pre-sale code, a seated session, a door rehearsal with real phones and a cancellation with batch refunds, and tells us where it does not match the night.

    Project stage: Client review

  6. Revisions

    Allocation behaviour, scanning speed, refund wording and settlement columns are adjusted from the review and re-checked against the scope document.

    Project stage: Revisions

  7. Ready for launch

    Events and orders migrated, payment and refund callbacks tested end to end, scanners paired, load tested at the expected on-sale peak, checklist signed off.

    Project stage: Ready for launch

  8. Delivered

    The venue sells and scans on the new system; optional maintenance and hosting continue under their own agreement.

    Project stage: Delivered

Integrations

Commonly integrated

Systems this kind of business usually asks us to connect. Each integration is confirmed during discovery; none is assumed.

  • Card payment providers for orders, fees and batch refunds
  • Email and SMS providers for e-tickets, reminders and cancellation notices
  • Mobile wallet passes for tickets on the phone
  • Handheld scanning hardware and printers for wristbands or paper tickets at the door
  • Accounting software for settlements, fees and promoter payouts
  • Mailing list tools for pre-sale codes and announcements
  • Resale marketplaces and external ticket agents, scoped per provider as integration opportunities

How we would approach it

Worked example

Concept demo

A three-day festival with five stages, camping tickets and twelve promoters

The situation

A festival sold weekend, day and camping tickets through two platforms, exchanged them for wristbands at four gates from printed lists, and settled with twelve stage promoters from spreadsheets weeks later.

Why it is a custom build

This needs a custom build because offline gate scanning across several entrances and per-promoter settlement on bundled ticket types sit outside what a shared ticketing platform lets an organiser control.

The scope we would propose

  • Ticket types that bundle camping and entry with allocations per day against the figures the organiser has recorded for each area
  • Timed tiers that move from early bird to general on a schedule
  • A seated arena session with a seat map and zone capacities
  • Gate scanning that keeps working when the signal drops and reconciles when it returns, with a live count per gate for the safety team
  • A wristband exchange record against each ticket
  • Refund and exchange rules per ticket type
  • A settlement per promoter per day with fees shown separately from face value

Concept demo: a scoping scenario written to show how we would approach the work. It is not a delivered client project.

Pricing

What affects the price

Every proposal is priced on scope. These are the factors that move it most for this kind of build.

  • Number of events per year and whether sessions, seating or both are needed
  • Seat maps: how many layouts and how often they change
  • On-sale peak: expected concurrent buyers when a popular event goes on sale
  • Door scanning: number of entrances, hardware, and offline operation
  • Refund and exchange rules and the payment provider involved
  • Promoters: how many, and the settlement format they need
  • Migration of future events and orders from current platforms
  • Hosting choice: your own hosting or ours

Start from a package

Event ticketing package

Ticket types with allocations and timed tiers, seated or general admission, e-tickets with QR codes, door scanning, refunds and promoter settlements for venues and promoters.

Custom build
View the package

FAQ

Frequently asked questions

When is the package enough and when do we need a custom build?

The event ticketing package covers events with ticket types, allocations and timed tiers, general admission and seated layouts, e-tickets, door scanning, refunds and promoter settlements with configuration. A custom build is the honest answer for multi-gate offline scanning at festival scale, bundled camping and travel products, resale integrations or very high on-sale peaks. Discovery tells you which before anything is quoted.

How does capacity work for a standing event?

The organiser records the figure they hold for that layout, and the system never sells past it across all ticket types and channels combined. Allocations divide that figure between tiers and pre-sales; a tier that does not sell out can hand its remainder back to general sale on a date you set.

What happens at the door if the internet drops?

The scanning page caches the ticket list for the event and keeps validating; scans are stored and reconciled when the connection returns, with a flag on any ticket scanned at two entrances in the gap. How much of this is needed depends on the venue and is settled in discovery.

Who owns the customer data?

You do. Buyers are your customers, held in your system, and their consent for marketing is recorded against each order. Source code and data are handed over at delivery; hosting and maintenance are optional and separately agreed.

Get a project quote for ticketing software

Answer a few questions about your business, your current systems and what should change. We reply with a clear, competitive proposal.

Get a project quote Discuss a partnership
Get a project quote

Cookies on this site. Strictly necessary cookies keep the site working. Allow first-party analytics so we can see which pages lead to enquiries. No advertising, no third-party trackers, no personal data; you can change this at any time on the cookies page.

Manage preferences