Case study
Owning the whole event, not renting pieces of it.
Most event organisers rent their stack: a marketplace takes a cut of every ticket, a cashless vendor charges per wristband, and both keep the attendee data. Encore Episode was built so none of that leaves the business.
01 / The problem
What was actually hard.
An event platform is deceptively hard because it is four systems that must agree with each other in real time and under load: ticketing, access control at the gate, payments on the ground, and settlement to vendors afterwards. A disagreement between any two of them becomes a queue, a dispute, or money that cannot be accounted for.
The load profile is also brutal and unforgiving. Sales are near-zero for weeks, then a release drops and thousands of people hit checkout in the same minute. At the gate, thousands scan within an hour, frequently on venue wi-fi that cannot be relied on.
02 / What we built
The system.
- Ticketing with real inventory control
- Tiered releases, coupons, categories and search, with QR issue and a guest 'find my tickets' route so a lost confirmation email does not become a support queue on the night.
- Gate validation
- One-scan QR validity with wristband pairing, so a screenshot forwarded to a friend does not get a second person through the gate.
- Cashless payments on the ground
- Tap-to-pay wristbands with self-service top-up in the app, replacing cash bars and the leakage that comes with them — on the organiser's own band stack rather than a per-event licence.
- Vendor portal with stall POS
- Invited vendors get their own event slots and a point of sale, with per-vendor settlement computed from the same ledger the wristbands write to.
- Refunds as a first-class workflow
- In-account refund requests for both tickets and wristband balances, with admin approval or rejection and a full audit trail — rather than the refund black hole the category is known for.
- Role-based access control
- Superadmin down through custom roles and granular permissions, because event staff, vendors and box office should not see the same data.
- Admin, reporting and exports
- Dashboards and CSV exports over the same records that drive settlement, so reconciliation is a query rather than a spreadsheet exercise.
03 / What carried over
Decisions worth reusing.
The parts of this build that we would apply again on a different problem in a different sector.
- One ledger, not four
- Tickets, top-ups, stall sales and refunds all write to the same accounting records. This is the decision that makes end-of-event settlement tractable, and it has to be made at the start.
- Degrade, do not stop
- Gate and stall operations are designed to keep working when connectivity does not, and reconcile afterwards. An event does not pause because the wi-fi did.
- Data stays first-party
- Attendee relationships and consent live in the platform, which is the entire commercial argument for building rather than listing on a marketplace.
04 / More work
Other builds.
Different sectors, the same delivery discipline.
Bits N Pixels
A software consultancy's site rebuilt as a platform — CMS, client portal, invoicing and multi-gateway payment links, with no CSS framework anywhere.
eSign Platform
An e-signature platform with envelopes, templates, a REST API and a tamper-evident certificate of completion behind every signed document.
Property Marketplace
A verified-first property portal — listings that carry evidence, in-app messaging, and a shortlist and visit flow built around actual buyer behaviour.
Next step
Have something like this to build?
Start with a diagnostic. It is fixed-fee, time-boxed, and it will tell you honestly whether the thing is worth building — including when the answer is no.