sector
ticketing platforms you own, and the door app that has to work with a queue forming
An owned ticketing platform with instalments and two native apps, a door-scanning app, and a social events estate spanning five codebases.
- £2M+
- processed on one platform
- nil
- third-party commission
- 4+ yrs
- on the longest estate
- 3
- surfaces: web, door, customer
Clutch
the problem
what this sector actually deals with.
Ticketing marketplaces take a cut of every ticket and own the relationship with your attendee. That trade is fine until volume makes it the largest line in your cost base — at which point you discover you cannot leave, because the platform holds the customer list, the payment history and the scanning app.
sound familiar?
- Per-ticket commission scales exactly with your success
- The marketplace owns your attendee data, not you
- Instalment plans and free tickets do not fit the standard flow
- Door staff need something that works on bad venue wifi
- Nobody notices the payment race condition until a live event
what we have built here
systems delivered in this sector.
An owned ticketing platform
Multi-organiser by default, with per-tier inventory, sale windows and no per-ticket commission — plus organiser tooling for upsells, post-purchase promotions, broadcast messaging and complimentary orders.
Instalments done properly
Instalment schedules with the ticket QR held back until full settlement, idempotency-keyed charges and automated failed-payment recovery.
A door app that assumes bad wifi
Offline-first React Native scanning: open camera, scan, green tick, next. Published to both stores with the internal team on the tester list before an event, not during one.
A social events estate
Four years across an app, its backend, a self-serve ads platform, a marketplace and the web front — including remote control over tab visibility so sections can be turned on without shipping a release.
the hard part
a check-in app has the most unforgiving failure profile in software.
It is used by non-technical staff, at a venue door, under time pressure, on poor connectivity, with a queue forming behind the person it is failing for.
- 01
That is why the app is offline-first rather than merely offline-tolerant, and why the scan loop is one gesture with one unambiguous confirmation.
- 02
It is also why the boring preparation is not process theatre: getting the internal team onto the tester list, and extending event date ranges on test accounts so QA works against realistic data, are the only ways to find problems before a queue does.
- 03
One store rejection worth naming, because it would block a launch: the build was refused for a missing camera permission description. On a ticket scanner the camera is the product, so a generic or absent usage string is a hard stop rather than a nuisance.
- 04
And on the platform side, the payment race condition — two paths completing the same order at a live festival — is written up in full on our fintech page. It is the same lesson from the other end of the same product.
what it runs on
the stack we reach for here.
Chosen for the sector requirements and for maintainability over the life of the system.
- Platform
- Laravel — public booking, organiser and super-admin, REST API
- Database
- MySQL, multi-organiser schema, instalment ledger
- Payments
- Stripe — idempotency-keyed charges, webhook reconciliation, row-locked completion
- Mobile
- React Native — offline-first check-in app and a customer app with push
how an engagement runs
what the first weeks look like.
Do the break-even first
Owning the platform is not automatically cheaper. We will model your commission against a build before you commit, and tell you if the answer is no.
Model inventory and money
Tiers, sale windows, instalments, comps and refunds decided up front — every one of them touches the ledger.
Ship the door app early
It needs a real event to be trusted, so it gets built and tested well ahead of the one that matters.
Stay for the first season
Live events surface things staging never will. We expect to be there for it.
selected work
written up in full
The engagements with the detail attached — and the numbers.
01
B2B commerceThe engineering partnership behind a cross-border wholesale marketplace.
Next.js storefront, Python ingestion pipelines, DynamoDB data layer and AWS infrastructure.
02A commission-free ticketing platform built for ownership and scale.
Multi-organiser commerce, Stripe instalments and two native apps in one connected platform.
03
Global logisticsEmbedded product engineering for a global shipping platform.
Rate, tax and duty calculators, server-rendered courier pages and a custom MongoDB CMS.
04A custom furniture marketplace engineered from storefront to infrastructure.
Server-rendered Next.js commerce over a Laravel API, bespoke operations tooling and re-architected AWS infrastructure.
05An AI-native operating system that runs a consultancy lead to invoice.
Discovery briefs, e-signed contracts, Stripe deposits, delivery milestones and time tracking in one operational system.
06A conversion platform for a growing UK boiler-cover provider.
Custom plan configuration, postcode-qualified lead journeys, CRM synchronisation and campaign landing pages.
07A custom Shopify store for a French beauty brand.
Custom theme, customer accounts, loyalty rewards, referrals and gift-with-purchase offers.
08Made-to-measure shutters with live pricing.
A seven-step product builder with live previews, sample orders and supplier tools.
09
AdvertisingA self-service advertising platform for venues.
Campaign creation, audience targeting, in-app ads and reporting linked to venue check-ins.
10Social eventsAn events app with the tools to run it.
Mobile app, backend, advertising tools, a digital marketplace and website.
11Two mobile apps for real-time companionship.
Customer and buddy apps with per-minute billing, wallets, moderation and admin tools.
12Player profiles and discovery for youth football.
Verified profiles, video highlights, coach discovery and safeguarding on web and mobile.
13Websites and a talent platform for DeepSpatial.
Corporate and investor pages, the Xploor talent platform and ongoing releases on AWS Amplify.
14
TravelTour bookings with a custom mobile-first checkout.
A multilingual website connected to the booking API, with deposits, coupons and affiliate tracking.
15One platform for tenders, contracts and accounts.
Supplier tenders, contract management, brokerage accounting and client records.
Teams that trusted us with the thing that matters
UK · Europe · Worldwide
the practices behind it
what this work is made of.
product engineering
Multi-tenant SaaS, marketplaces, ticketing and booking engines — the systems your business actually runs on, built to survive their own success.
native mobile
React Native apps that ship past App Store review and stay shipped — offline-first paths, push, real-time sync and over-the-air updates.
web & commerce
Headless WordPress, Shopify and custom checkouts wired to whatever proprietary API the business already depends on.
reviews · verified on clutch
the people who signed off the work
Clutch★★★★★5.0 / 5.0Across 18 independently published client reviews
“They have a deeper technical knowledge than any web designer I've met to date.”
faq
questions from this sector
Is building cheaper than paying commission?
It depends entirely on your volume and ticket price, and we publish a break-even study on it. If the numbers say stay on the marketplace, that is what we will tell you.
Can it handle instalments?
Yes — with the ticket withheld until full settlement, which is the part most implementations get wrong.
What about free tickets?
Zero-value orders need the payment path overridden entirely rather than charged for zero. Sounds obvious; is a common source of broken checkouts.
Can multiple organisers use one platform?
Yes, that is the default architecture — new organisers onboard without engineering work.
keep reading
the other sectors we work in.
paying commission on every ticket you sell?
A thirty-minute call with the engineer who would lead the work.