GigWizard Marketplace

Overview

GigWizard is a production two-sided marketplace connecting event organisers with live music performers. I designed and built the platform end-to-end, covering mobile and web clients, backend workflows, payments, and production operations. The system manages the full booking lifecycle, including discovery, offers, confirmations, secure payments, and post-event completion.

Problem & Constraints

The live music booking space is fragmented and largely manual, creating friction and trust issues for both organisers and performers.

• Complex lifecycle: Bookings progress through multiple states and user actions, requiring strict and predictable state transitions.
• Trust & safety: Payments needed to be securely held and released only after event completion.
• Operational simplicity: The system needed to be maintainable by a small team without heavy DevOps overhead.
• Cost awareness: Infrastructure choices had to keep operating costs predictable at low-to-medium scale.

My Role

I owned both product and technical execution.

• Defined system architecture, data models, and booking/payment lifecycles.
• Implemented core application logic across clients and backend workflows.
• Integrated and operated secure payments.
• Deployed, monitored, and iterated on the system in production.

System Design

The platform was designed with a serverless-first architecture to reduce operational overhead and simplify scaling.

• Clients: Mobile-first applications supported by a web interface.
• Backend: Event-driven serverless workflows handling booking and payment state transitions.
• State management: Explicit lifecycle states to ensure correctness and recovery.
• Payments: External payment provider coordinated through asynchronous callbacks and idempotent processing.

Key Decisions & Trade-offs

• Serverless over always-on services: Reduced infrastructure complexity and operational burden.
• Explicit state transitions: Chosen to prevent duplicate processing and simplify failure recovery.
• Eventual consistency: Accepted in non-critical paths to reduce coupling and improve resilience.
• Custom payment flows: Prioritised full control over user experience at the cost of higher implementation and compliance effort.

Outcome & Learnings

• Launched successfully with real users and active bookings.
• Reliable handling of complex booking and payment flows with no integrity issues.
• Predictable infrastructure costs under real-world usage.
• Clear operational paths for handling retries, failures, and disputes.

Tech

Flutter · Firebase · Stripe · Next.js