Ticketing for operations with physical constraints.
Scenic railways, tours, boats, venues. Places where a seat is not just a seat, a cancellation is hundreds of refunds, and the experience continues after the ticket is scanned.
The problems we keep seeing
- Seats are assigned, not chosen.Weight distribution, car logic, accessibility, or vehicle layout decide where people sit. Guests still expect to sit with their party.
- Cancellations happen all at once.Weather, mechanical, closures. Every guest on the departure needs a refund and a message, and staff should not touch each one.
- Boarding is a queue.Paper lists and name lookups move slowly. Scannable passes and a staff validation flow move faster.
- The venue has no signal.Canyons, water, remote track. Anything the guest uses on board has to work offline.
- The old system is a monthly cost with no commitment behind it.A revenue-critical platform deserves a written SLA.
Five parts,
one system.
Assignment as an algorithm.
Guests book by departure and party size. An assignment engine places every passenger according to the operator's physical rules. Separate reservations can be linked so groups are seated together within those constraints. Staff override any seat; the engine re-validates in the background.
An operations console built for the worst day.
Per-departure color-coded seat maps. Manual reassignment. Cancel an entire departure in one action, with every guest refunded through Stripe and notified by email automatically. Invoicing and check-in from the same screen.
Stripe Connect as the commercial model.
Funds settle directly to the operator's Stripe account. A per-transaction platform fee is collected automatically, credited back on refunds, and reported monthly. Auditable from the Stripe dashboard at any time.
Offline-first native app.
Narrated tour, synchronized subtitles, switchable languages and narrator voices, all pre-downloaded to the device. Seat assignment and departure details in the same app.
Real-time availability calendar.
Departures, times, and remaining capacity per train, on phone and desktop.
The engagement
| Phase | Deliverable | Typical window |
|---|---|---|
| 01 · Discovery & design | Seating-algorithm specification, data model, UX, payment architecture | 4–6 weeks |
| 02 · Core build | Booking flow, assignment engine, linked bookings, payments, calendar | 8–10 weeks |
| 03 · Console & check-in | Seat maps, overrides, cancellations and refunds, invoicing, validation | 4–6 weeks |
| 04 · Beta & training | Staging, real-data rehearsal, staff onboarding | 3–4 weeks |
| 05 · Launch & operate | Live sales, then managed service with one-hour response for booking outages | Ongoing |
Discovery and algorithm specification first, then a milestone build with weekly demos, then a staged beta with staff training on real data before launch. After go-live: managed service with infrastructure included, one-hour response for booking outages, and a platform fee that means Stay Wired earns only when you sell.
Stack: Next.js · Vercel · Supabase Postgres · Stripe Connect · Resend · native iOS and Android
Request a proposal