TicketHub

TicketHub is a full-stack event ticketing and operations platform designed around the entire journey from discovering an event to physically entering the venue.

What began as a ticketing product quickly became an infrastructure problem.

From the outside, buying a ticket appears simple:

Behind that interaction are inventory rules, capacity, payment state, ticket fulfilment, promoters, venues, refunds, staff permissions, notifications, fraud considerations, event discovery, check-in and potentially unreliable connectivity on event day.

TicketHub became an exercise in designing all of those moving parts as one coherent system.

TicketHub serves several users whose needs are completely different.

Buyers want discovery, fast checkout and easy ticket access.

Promoters want event creation, sales, marketing, staff management and analytics.

Gate staff need one thing: validate tickets as quickly as possible.

Sales agents need controlled selling workflows.

Administrators need system-wide visibility and operational controls.

Trying to force those personas into the same interface would make every experience worse.

TicketHub is therefore structured as multiple focused applications backed by shared platform infrastructure.

The product progressively reveals complexity.

A small organiser creating a simple event should not have to understand advanced zone rules, payout structures or dynamic pricing before publishing.

A large promoter should still have access to those capabilities when needed.

That is progressive disclosure applied to business software.

The checkout system is one of the most important parts of TicketHub.

Inventory cannot simply be counted.

It must be safely reserved.

If two people attempt to purchase the last ticket simultaneously, the system must know who actually owns that capacity.

The transaction therefore moves through a controlled lifecycle:

Inventory is reserved temporarily.

Reservations expire.

Expired capacity returns to inventory.

Payment confirmation controls fulfilment.

Completed order records remain historically reliable.

Ticket generation happens only when the appropriate transaction state has been reached.

Most users will never know these systems exist.

That is the point.

Reliable software makes difficult problems disappear from the user's mental model.

Once an order completes, TicketHub supports multiple delivery paths including QR-based tickets and downloadable ticket formats, with the platform designed around additional delivery channels such as digital wallet passes and messaging-based delivery.

Ticket ownership, transfers and validation require auditability because the ticket becomes an access credential, not simply a PDF.

TicketHub is also designed as a buyer experience rather than only checkout infrastructure.

Discovery becomes part of the lifecycle.

That gives the system the foundation for long-term customer relationships rather than one-off transactions.

Event-day software operates under completely different conditions from normal SaaS.

People are waiting.

Queues are growing.

Noise is everywhere.

Connectivity may be unstable.

The interface cannot require careful thinking.

At the gate, the central question becomes:

Valid or not?

Offline behaviour is not treated as an edge case.

An event does not stop admitting people because mobile data stopped working.

TicketHub also became the project where I formalised many of my product design principles.

The interface follows rules such as:

View first.

Show the user what already exists before asking them to create something.

Progressive disclosure.

Expose advanced controls when they become relevant.

Strong defaults.

The system should make sensible decisions before asking users to configure everything themselves.

Next-step chaining.

Every major action should naturally suggest what happens next.

Guardrails before errors.

Prevent invalid actions wherever possible instead of explaining them afterwards.

Truthful states.

If something is processing, queued, failed, pending or unavailable, the interface should say so.

TicketHub also forced me to think beyond the happy path.

What happens when payment succeeds but fulfilment fails?

What happens when somebody refreshes during checkout?

What happens when a reservation expires?

What happens when a promoter postpones an event?

What happens when a ticket gets scanned twice?

What happens when the scanner has no internet?

What happens when notifications fail?

Those questions are not edge work.

They are product work.

TicketHub is probably the clearest representation of how I approach software engineering.

I can begin with a screen.

But eventually I will ask about:

the database,

the state machine,

permissions,

transactions,

queues,

network conditions,

failure modes,

business rules,

security,

notifications,

operational workflows,

and the person standing at the gate trying to admit thousands of people.

Because the interface is only the visible layer.

Great software is everything that has to work before the interface can feel effortless.