TourTicketz
A booking and ticketing platform for operators who sell a place on a schedule. It gives each one a branded storefront on their own domain, a booking engine that understands capacity, a walk-up sales desk sharing the same inventory, and a double-entry back office waiting behind a switch for the day the books start to matter.
TL;DR
At a glance
Branded
Own domain
Storefront per operator, not a marketplace listing
Web + desk
One inventory
Online and walk-up sell the same slots
Double-entry
Every movement
Balances derived from the ledger, never typed
QR scan
At the door
Redemption gated by role permissions
The Problem
Two bad options, and nothing in between
An operator selling timed experiences usually has two choices. Run it themselves — a spreadsheet of departures, a phone that rings during tours, a paper ticket book, and a cash box nobody reconciles until something is missing. Or list on a marketplace, which solves the selling but takes a cut of every booking, owns the customer relationship, and leaves the operator renting access to their own demand.
Neither option gives them a shop. And the moment a business grows past one person, a second problem arrives that no booking widget addresses at all: the money. Who sold what, from which branch, on whose commission, into which drawer, and does the total at the end of the day actually mean anything.
What We Built
A shop, a desk, and the books behind them
TourTicketz is one platform with three surfaces. A public storefront each operator brands and publishes on their own domain. A sales desk the staff use for walk-ups, scanning and day-to-day operations. And a back office — ledger, cash, commissions, procurement, reporting and audit — that stays out of the way until it is switched on.
Payments settle into the operator's own connected Stripe account rather than passing through us, and there is no per-booking fee on top. That single decision shapes the whole positioning: the operator owns the customer, the money and the domain, and pays a flat monthly fee for the software.
Technical Highlights
Eight decisions that shaped the build
One inventory, two channels
The front desk is not a separate system. A walk-up sale is a multi-line booking against the same slots the storefront sells, so a busy morning at the counter shrinks online availability in real time. While a traveller is in checkout their seats are held, then either confirmed or released — capacity is enforced per slot, and the platform is built so a slot cannot be oversold from either side.
Schedules that expand into real occurrences
Operators think in rules — every Tuesday and Thursday at 09:30, twice daily in summer. The booking engine expands those recurring rules into concrete, individually bookable occurrences months ahead, each carrying its own capacity, price and status. That is what makes a calendar sellable rather than merely displayable.
Money is posted, never typed
Every sale, refund, void and transfer posts a balanced double-entry transaction. No balance anywhere in the product is a number someone entered — each is derived from the ledger. It costs more up front than a running total in a column, and it is the reason the year-end figures reconcile instead of being argued about.
Commissions frozen at the moment of sale
Promoters and agencies earn on flat, percentage or per-ticket-type rules, and those rules change. The commission owed is snapshotted onto the sale as it happens, so editing a rule in March cannot silently rewrite what was owed in January. Retroactive maths is the fastest way to lose a partner's trust.
Reversing entries instead of edits
The audit trail is append-only and money operations are idempotent, so a retried request cannot double-charge or double-post. A mistake is corrected by posting its reversal, not by editing history — which means the books always explain themselves, including the mistakes.
Tickets that survive contact with the door
Each booking issues QR tickets, delivered by email as codes plus a scannable pass. At the entrance a scan station handles them, built for the handheld and wedge scanners venues already own rather than assuming a staff member has the right phone. Redemption is a permission like any other, so who may let people in is a decision the operator makes.
Receipts on the hardware the desk already has
Counter sales print sequential, per-branch receipt numbers straight to 58 mm and 80 mm thermal printers over ESC/POS, with a matching PDF for anyone who wants the file instead. Receipt templates are configurable per tenant, because a receipt is often the only paperwork a walk-up customer ever gets.
The back office is a switch, not a migration
Operators do not want accounting on day one; they want it the day the books start to matter to someone else. Turning it on is a toggle in settings — no second account, no data import, and no gap in the history, because every sale taken up to that point was already posted to the ledger as it happened.
Architecture
One monorepo, three deployables
The storefront, the operator app and the API ship from a single TypeScript monorepo, sharing a schema-validated contracts package and a domain layer so business rules live in exactly one place. Nothing about a sale is re-implemented per surface.
Storefront
- Next.js App Router
- Multi-tenant routing per operator
- Custom domains per storefront
- Per-tenant SEO: sitemap, robots
- Cart, coupons, Stripe checkout
Operator app
- Next.js + tRPC, end-to-end typed
- TanStack Query & Table
- Permission-driven RBAC per tenant
- PDF and Excel/CSV exports
- ESC/POS thermal receipt printing
API & domain
- NestJS with OpenAPI docs
- Argon2 credentials + OAuth
- Redis for caching and jobs
- Object storage for media
- Transactional email delivery
Data
- PostgreSQL via Prisma
- Double-entry ledger tables
- Append-only audit trail
- Idempotent money operations
- Dockerised, deployed from CI
Want something like this built?
We design and ship complete products — storefront, operations tooling and the accounting underneath — not just the screens on top.