The QR ticket problem we didn't see coming
Three weeks after FlashSeat launched, a user messaged support at 11 PM on a Friday. She'd bought a ticket to a sold-out comedy show at the O2 for half price, but her phone had 3% battery. She was standing in the queue outside, and the venue's WiFi wasn't reaching the entrance. She couldn't display her ticket. That message changed how we thought about the entire app.
When your biggest feature is useless when you need it most
The ticket arrived in her email, sure. But we'd designed FlashSeat around speed. Three steps from search to confirmed booking. Push notifications the moment a deal matched her saved searches. In-app checkout so she never had to leave to pay. We'd optimized for the moment of impulse, the split-second decision. What we hadn't optimized for was the next moment: actually getting through the door.
Event venues, especially big ones, have patchy networks. Venues that host the kinds of shows and matches our users hunt for. A user might buy a ticket to a gig in Kings Cross with 20 minutes to spare, jump on the Underground, and arrive with zero signal. Their phone battery might be knackered from the day. They're stressed. They're excited. They need their ticket to work.
We started digging into our support inbox. Not a flood of complaints, but a pattern. Three, five, then twelve users with the same issue. Some venues wanted a printed confirmation code. Some had required PDF downloads. All of it friction. All of it antithetical to what FlashSeat was meant to be.
The offline QR code was the only answer
We looked at the standard solutions. Most ticketing apps stream the barcode fresh when you open them, which means you're reliant on connectivity. Some require a screenshot. Some ask you to generate a code at home and remember to take it with you. None of that felt right for a service built on spontaneity.
We built the QR ticket directly into the app with one requirement: it had to work offline and at full brightness. The moment a user completes checkout, that ticket generates locally on their phone. No network call. No delay. They can show it at the venue on the lowest battery, the slowest connection, the worst signal dead zone. It sits there in the app, bright enough to scan under almost any lighting condition, ready whenever they are.
It sounds simple, but the implementation meant rethinking how the app cached and displayed ticket data. We had to ensure the QR code couldn't be duplicated or shared, that it was unique to the person who bought it. We had to test it against the most common venue scanning hardware. None of it was technically impossible, but it required treating the ticket display as a first class citizen in the design, not an afterthought.
Building for the moment after the deal
When I started MRVL Technologies, the brief for FlashSeat was simple: make last minute deals on flights and events accessible to people aged 18-40 who actually want to go. Not people hunting for their next investment. People who see a ticket to something brilliant and think, I'm doing that this weekend.
That means the app has to work for people who book at 6 PM for a show at 9 PM. People who grab a flight deal during their lunch break. The QR ticket feature isn't glamorous. It won't appear in marketing materials next to the flash deals or the members-only early access. But it's the difference between a booking being complete and a booking being useful.
We've now had users who've bought tickets with two minutes of battery left, arrived at venues with no signal, and walked straight in. No screenshots. No printed codes. No panic. The feature solved something we didn't build the app to solve, but should have.
What this taught us about spontaneous travel and events
The QR ticket feature exposed something deeper about how people actually use deal-hunting apps. It's not a leisurely process. Someone isn't browsing FlashSeat for an event six months out. They're checking saved searches on their commute, they're scrolling at work, they're seeing a notification about early access to a members-only flash drop and making a decision in seconds.
They then have to get somewhere, fast. Sometimes very fast. The app can't assume WiFi, battery, or foresight. It has to assume chaos.
That shaped how we approach features now. When we added saved searches with deal alerts, we built them to work with minimal data so the notification doesn't drain battery. When we designed the three-step checkout, we made sure each step was fast enough that you could complete it at a bus stop. The QR ticket was just the most obvious expression of that principle: the app's usefulness ends the moment you leave your phone.
It's easy to build around the thing users came for. It's harder to build for what they need after they've already bought. How many features in apps you use do you think were born from a user's 11 PM panic message?