Case study — Platform
One booking platform for every stadium in the network, for Venues NSW
- Project type
- Custom Platform · Booking & Event Management
- Our role
- Discovery · Design · Development · Ongoing Delivery
- Technology
- Laravel · Next.js
The problem
Venues NSW runs the state’s major stadiums and entertainment venues. Booking them was handled by a legacy third-party system that the organisation had outgrown: it did not model the way spaces are actually sold, it could not express the provisional holds that commercial venue sales depend on, and the data it held was difficult to get out and into the other systems a venue runs on.
That last point matters more than it sounds. A stadium is not just a calendar. What is booked, where, and when drives building services, staffing, and the systems that let people through the door. When the booking system is an island, everything downstream is manual.
Our approach
We built Booka: a single booking and event-management platform for the whole venue network, designed around how venue teams actually sell and run space.
Bookings that match commercial reality. Venue sales rarely move straight from enquiry to confirmed. Booka models tiered provisional holds, so a space can be held with a clear signal of how firm that interest is, and the strongest commercial intent wins the slot. Spaces that need sign-off are marked as requiring approval and route to an approver rather than being bookable outright.
Conflict detection across a space tree. Venues are hierarchical — a stadium contains concourses, which contain rooms, which can be combined or subdivided. Booking one thing implicitly books others. Booka understands those relationships and refuses to double-book, rather than leaving it to whoever notices first.
The event, not just the slot. Reusable staffing templates become per-event rosters, and run sheets turn an event day into a time-ordered checklist. The information that used to live in a spreadsheet beside the booking system now lives with the event.
Governance built in. Role-based access runs per venue, so a team manages its own venues without seeing everything else, and a separate permission set governs who can see other people’s contact details. Every consequential action is written to an audit log — for a public body, being able to show what changed and who changed it is not optional.
Integrations, so the platform is not an island. Single sign-on runs through the organisation’s existing Microsoft identity, so there is no separate account to manage. An external API exposes event and space data to the building management system, which uses it to schedule HVAC, lighting and security around what is actually on. The legacy platform was retired venue by venue rather than in one risky cutover, with both systems kept in step through each transition until the last one was done.
The build
Booka is a Next.js and TypeScript application over a Postgres database, with tenant isolation enforced at the database layer rather than only in application code. Transactional mail runs through AWS SES, error monitoring through Sentry, and every deploy goes out through an automated pipeline that runs the unit and end-to-end suites, applies database migrations and ships the frontend in one sequence.
It is a long-running engagement rather than a project that shipped and stopped: more than four thousand commits and over a hundred and thirty database migrations to date, and still being extended now that the whole network depends on it.
The outcome
Every stadium in the Venues NSW network is now live on Booka. One platform the organisation owns, with the commercial nuance its teams need, the audit trail a public body requires, and an integration path that lets the booking system drive the building rather than sit beside it.
The legacy system it replaced is gone.
Booka is an internal platform for venue staff — there is no public-facing surface.
Start a conversation
Start a conversation
Tell us what you want to build, fix or scale — we’ll come back with a clear way forward.