Real-Time Booking & Ticketing Engine
End-to-end checkout with dynamic seat mapping, multiple pricing tiers, promo-code processing, and a synchronised seat-hold countdown that releases inventory automatically when a checkout is abandoned.
Loading
Ticketing & Events
A progressive web application for a creative theatre community, combining a public storefront, real-time ticket booking, and a full administrative dashboard for event and venue management.
01 · Stack
| Layer | Technologies | Key libraries |
|---|---|---|
| Frontend Framework |
|
|
| UI & Styling |
|
|
| Backend / Runtime |
|
|
| Database & Cache |
|
|
| Authentication |
| · |
| Hosting & Infrastructure |
|
|
| Integrations & APIs |
|
|
A thematic "Stage" system: deep theatre-dark backgrounds (#020617, #0F172A) evoking a house before curtain, cut with vivid sky-blue accents (#0EA5E9) standing in for stage lighting. Lora carries the headings as a premium serif, with Manrope handling body copy.
Split by domain rather than by type, so the booking flow, the checkout, and the admin console each own their components. The shared GlassCard primitive implements the frosted 16px-blur treatment used throughout.
React Context for cross-cutting concerns (AuthProvider, ToastProvider), with custom hooks driving the booking flow and real-time UI such as the seat-hold countdown timer.
Scales from a stacked single-column mobile layout to multi-column desktop grids with interactive seating charts. Accessibility is built into the primitives · AriaButton and AriaInput wrappers, skip links, semantic HTML, and full keyboard navigation through the seat map.
App Router server rendering and static generation for the marketing surface, with Turbopack driving both development and production builds.
A serverless blend of Next.js Server Components, API Routes, and Firebase Cloud Functions, composed into a scalable monolith rather than split into services that would not have earned their operational cost.
Seven Firestore collections modelling the real domain · a play is distinct from an event, and a venue's seating configuration is distinct from a given night's pricing, which is what makes per-event pricing tiers possible.
Firebase Auth with Firestore Security Rules isolating user data and restricting every dashboard surface to authenticated admins, enforced at the database rather than by route guards alone.
Payment endpoints are the only public write surface, and both validate server-side before touching a booking.
04 · Features
End-to-end checkout with dynamic seat mapping, multiple pricing tiers, promo-code processing, and a synchronised seat-hold countdown that releases inventory automatically when a checkout is abandoned.
A successful transaction immediately mints a booking ID and QR code, rendered client-side into a downloadable PDF ticket via jsPDF and QRCode · with a QR per seat, not merely per booking.
Role-protected CRUD across plays, venues, and events, plus visual analytics through Recharts covering revenue, ticket sales, and top-performing events, with CSV export and date-range reporting.
Animated pages presenting the organisation's eight-wing creative ecosystem, a timeline-based origin story, and crew portfolios · the acquisition layer that feeds the booking engine.
05 · Standout engineering
Every project has two problems that determined whether it worked. These were theirs.
A flexible venue model that lets an administrator configure arbitrary seating layouts and then segment them into different pricing tiers per event, rendered as an interactive seat map. The same venue supports a premium gala and a low-price community night without a developer touching the code.
A stateful checkout that guarantees transactional integrity by composing Next.js server routes, the Razorpay SDK, and Firebase transactions · so a seat cannot be double-booked while a payment is still pending.
06 · Engineering practice
├── src/ │ ├── app/ │ │ ├── (public)/ # Landing, about, crew, ecosystem, events │ │ ├── admin/ # Role-gated management console │ │ ├── api/ # Payment order + verification │ │ └── checkout/ # Transactional flow │ ├── components/ │ │ ├── admin/ │ │ ├── booking/ │ │ └── ui/ # GlassCard, AriaButton, AriaInput │ ├── data/ │ ├── lib/ │ └── types/ │ └── booking.ts # The domain's core contract └── next.config.ts
TypeScript 5.9 in strict mode, ESLint 9, and zod schemas shared between client and server so a payload validated in the browser is validated identically on the server.
Vercel edge deployment, with static marketing pages and dynamically server-rendered dashboard and checkout routes in the same application.
07 · Impact
Route-level code splitting and optimised image rendering keep the booking path light · the seat map is the only heavy view and it loads on demand. No Lighthouse figure is published here because none has been measured on production traffic.
Firestore real-time reads combined with Vercel serverless absorb sudden traffic spikes · the pattern where an anticipated play opens for booking and demand arrives all at once · without bottlenecking.
08 · Interface
Contact
The best fit is a business that needs a system to hold up under real use · not a template with your logo on it.
