A founder-built booking and event operations platform designed to connect artists, agents, promoters and venues across the lifecycle of a live event — from enquiry and offer through delivery, settlement and reporting.
Real application captures from the project. Screens are presented as product evidence; sample names, ticket counts and financial values are illustrative data.
Delivered outcomes come first. The remaining categories show what is implemented, what has test evidence, what is deployed and what is still staged or planned.
What reached users, operators or an upstream project — the outcome, not just the code.
Capabilities evidenced in source code or project documentation.
Automated test coverage or documented test evidence; not a blanket passing-build guarantee.
Live product surfaces or historically operated deployments, with scope stated.
Known release boundaries, future work or areas not claimed as complete.
Independent event work is fragmented across messages, spreadsheets, booking tools, ticketing, production documents and finance systems. The product direction is to bring those workflows into a connected platform without flattening the different roles and organisations involved.
Build a multi-tenant platform with an artist/agent booking layer and a promoter operations layer, supported by a native iOS client and a versioned API. Keep organisation boundaries explicit in the data model and enforce approval rules in the database rather than relying only on interface behaviour.
The web dashboard and native iOS client work against the same versioned API and tenant-scoped data layer.
Dashboard · Public events · EPK · Admin
Event operations · Tickets · QR · Calendar
Stripe · AI Gateway · Email · Webhooks
Authentication · Roles · Validation · Domain services · Approval rules
Organisation-scoped records · Row-level security · Migrations · Audit history
Production web deployment · Migration gate · Observability and iteration
SwiftUI iPhone client for event discovery, promoter operations, ticketing, QR check-in and calendar hand-off
Next.js 16 web dashboard, public event and EPK surfaces, and versioned /api/v1 endpoints
PostgreSQL 18 data layer with organisation-scoped row-level security, explicit migrations and tenant-aware relational constraints
Event operations domain covering rooms, lineups, ticket tiers, guest lists, crew shifts, timesheets, equipment hire, purchase orders, supplier invoices, site plans and run sheets
Commercial workflows spanning proposals, sponsorship packages, client acceptance, deliverables, renewals and online ticket checkout
Finance and reporting layer for event budgets, break-even, VAT and FEU estimates, settlements, invoices, payment dates, cash flow and CSV exports
AI drafting through Vercel AI Gateway with deterministic template fallback when the gateway is unavailable
Production deployment workflow that applies ordered database migrations before release and stops deployment if a migration fails
Tenant-owned records carry org_id and use PostgreSQL row-level security keyed by app.org_id. This makes tenant isolation part of the persistence layer.
Outbound touchpoints cannot enter the sent state without an approved_by identity. The database constraint makes the approval requirement explicit.
The Next.js application exposes a versioned /api/v1 surface so the native client and web product share backend workflows.
AI-assisted drafting uses Vercel AI Gateway when configured; otherwise the product can fall back to deterministic templates.
The iOS event workspace exposes lineup, rooms, ticket tiers, QR scanning, guest lists, crew, site plans and run sheets. The web Settlement Vault reconciles advance tickets, door and bar takings, other income, artist fees, withholding and operating costs against the same event.
The product distinguishes current ticket pace and late-sales forecasts from actual night-of-event takings and the final settlement. This avoids presenting a forecast as realised income.
Production builds run an ordered migration runner using a direct owner connection, a migration ledger and an advisory lock. A failed migration stops the build so the previous production version remains in service.
A dedicated performance phase added a seeded dataset and measurement script, reducing the events-list query count from roughly 2,000 to six and removing nested list scans from reporting, hire and proposals.
The online ticket flow uses Stripe Checkout on the organiser's connected account, holds places while payment is in progress, issues tickets only after confirmed payment and defines expiry and late-payment refund handling. The documented implementation is in Stripe test mode unless explicitly switched live.
Hardening work added composite organisation-aware keys to event child tables and tightened ownership checks so one tenant cannot write against another tenant's event.
Webhook delivery was hardened against SSRF by restricting destinations to globally routable addresses and rechecking resolved addresses at connection time.
Email sending caps, role checks, short-lived secret hand-offs, CSV formula-injection protection and QR-login safeguards were added to the API surface.
Promoter workflows model VAT, overseas artist withholding, budgets, break-even and event-level settlement rather than treating an event as a simple calendar entry.
Event setup surfaces missing security, insurance, welfare and marketing cost inputs as warnings, while production tools cover crew call sheets, site plans, room configuration and timed run sheets. These are planning prompts, not automated certification of legal compliance.
The native app provides on-the-go event and promoter workflows; the web dashboard provides deeper administrative and settlement views, including printable financial records.
Recent delivery phases extend the event model into crew, equipment, compliance evidence, incident records, sponsorship and business reporting. These capabilities share the organisation and event context rather than living as disconnected mini-apps.
The platform distinguishes test-mode checkout from live payment processing. Ticket issuance is tied to payment confirmation, while checkout holds expire and late successful payments follow a refund path.
Discobobulated / Booking OS is a founder-built product in active development. Recent repository history documents delivery phases for crew operations, equipment hire, compliance records, sponsorship, reporting, performance work and Stripe ticket checkout. Ticket checkout is explicitly documented as test mode unless switched live; do not imply live card processing without separate production verification. The performance commit reports a reduction in the seeded events-list query count from roughly 2,000 to six; this is a repository-reported test result, not a general production latency claim. Screenshots use sample application data, not evidence of realised revenue. Compliance workflows support evidence and operational readiness but do not certify legal compliance. Not every module is generally available or production-complete.
Tell me what you are trying to build. We can scope the right next step.
