Three brands, four squads and a new way to buy a Burger King.
Prepaid offers let a guest pay for a meal today and eat it on another day. I led the discovery that designed it, from the ad to the restaurant counter. The pilot is being rolled out in the Netherlands.
My roleDesign Leadfor Restaurant Brands InternationalFeb 2025 – Mar 2026
Paying and eating are two islands. Scroll to build the bridge between them.
01The remitTwo islands
Feb 2025
I led five designers across three restaurant brands. One of our four workstreams asked a new question: could guests pay for a meal now and eat it later?
In the scenePaying and eating sit on separate islands.
02The betThe gap
Jun 2025
Starbucks already holds $1.75B in customer balances. Burger King had no way to sell a meal for another day.
In the sceneStarbucks has a bridge. Burger King has a gap.
03ReadinessSix supports
Jul 2025
A purchase with no meal attached touched six systems. None were ready: four partly, two at risk.
In the sceneSix supports go up; two are too short.
04Where trust breaksThree holes
Aug 2025
We expected guests to doubt the deal three times: while deciding, right after paying and at the counter.
In the sceneThe walkway goes down with three holes in it.
05The turnNo shortcut
Aug 2025
I argued that a prepaid meal is paid for, not earned, so it cannot run on loyalty rules. The PMs agreed.
In the sceneThe shortcut through loyalty is ruled out.
06The designThe path
Sep 2025
One dedicated path from the ad to the counter. After paying, the screen tells guests their meal is saved in Offers.
In the sceneThree holes filled: the saving, Saved to Offers, the cashier code.
07The disciplineHeld back
Oct 2025
Anything that needed deep platform changes before guests had shown they wanted it was held back: 22 features.
In the scene22 held-back pieces wait on the side.
08The resultRolling out
Rolling out in the Netherlands: one market, one meal, one flow, to be measured against the tracking plan I wrote.
In the sceneA prepaid order crosses from paying to eating.
01The remitIn the scene: two islands
Five designers, three brands and one question nobody had asked.
As Design Lead I ran the discovery that asked whether Burger King could sell future meal value, and took it to a pilot in the Netherlands: a test in one market, with one meal, before any wider rollout.
Burger King
Popeyes
Firehouse Subs
Four squadsCore FrontendTransactionsEngagementIberia
Design System v02
31 React components built with Core FE and QA, with Design QA inside the sprint.
Design QA in sprint
Drift caught before release, plus Figma inspection workshops for developers.
Intake and classification
Requests sized with PMs and BAs before sprint planning, not during it.
Cross-stream review
One review across four streams before any client review.
Of the four, one carried the most commercial risk and the least existing pattern. The rest of this study is that one.
02The betIn the scene: the gap
Two receipts. One of them has a place to keep the money.
Burger KingCounter · paid and eaten today
Whopper Meal£6.49
Large Fries£1.99
Diet Coke£1.29
Total£9.77
Pay now, eat laterNot possible
Illustrative receipt
StarbucksApp · paid from stored balance
Grande Caramel Latte£5.50
Blueberry Muffin£3.25
Stars reward−£0.50
Total£8.25
Balance held for laterStored value
Illustrative receipt
$1.75B
Stored value and loyalty balance Starbucks held, 28 Sep 2025
$222M
Starbucks breakage in fiscal 2025: paid for, never redeemed
None
Burger King stored value: no wallet, no float tracking
Source: Starbucks Form 10-K, fiscal 2025
Where Burger King stood, June 2025
How its app compared with the brands that already let guests pay ahead, capability by capability.
Capability
Burger King, Jun 2025
Best in class
Stored value
None or minimal
Starbucks in-app wallet, auto-reload
Loyalty
Crown Rewards, flat points
McDonald's tiers, Starbucks status
Subscription
None
Pret coffee subscription, DoorDash DashPass
B2B and vouchers
None
Corporate gifting at scale
Buy now, use later
None
The gap this discovery set out to close
What franchisees asked for
Lead with the saving, not the price.
Time the messages around paydays.
Clearing needs an answer for franchise accounting.
Digital Masters 2025, Nice
The market had already proved the model. Nobody had asked whether Burger King's platform could hold it.
03ReadinessIn the scene: six supports
Six systems. Not one was ready.
Each had to answer one question before a guest could pay now and eat later. From July to October 2025 I wrote 14 weekly summaries tracking the answers.
0
Ready
4
Partial
2
At risk
Status
System
The question
What we found
Partial
Ads and attribution
Can attribution survive the tap?
Setup varies by region
Partial
Deep links
Can a link carry one exact offer?
Offer ID persistence unverified
Partial
Payments (PSP)
Can we charge without fulfilling?
New orchestration needed
Partial
Loyalty and offers engine
Can it store redemption state?
Real-time sync unverified
At risk
CRM
Can it fire on expiry?
Prepaid triggers not configured
At risk
POS
Can a restaurant accept it?
Varies by market and franchisee
No system said no, and none said yes. So the first design decision was what to test, not what to draw.
04Where trust breaksIn the scene: three holes
Three places a guest stops believing the money is safe.
A hypothesis, not a measurement. The three dips are where the design had to work hardest.
Expected trust, stated before testing · hypothesised, not measured
01Ad impressionHopeful
02Click and landingCurious
03Offer explorationUncertainAnswered by screens 0102
04PurchaseAnxious
05Stored in appConfusedAnswered by screens 0304
06ReminderRelieved
07RedemptionWorriedAnswered by screens 05
08Post-redeemResolved
Five bets the pilot was built to test
Written before anything was drawn. If a bet holds, the risk beside it goes away.
ID
Hypothesis
Risk it retires
H1
Guests will buy prepaid items even if they cannot redeem immediately.
Model risk
H2
Reminders 48 to 72 hours before expiry lift redemption.
Redemption risk
H3
New guests respond to value; existing guests to convenience and variety.
Audience risk
H4
Redemption works better in the app than at the counter.
Operational risk
H5
Personalising the offer (drink or fries) lifts purchase intent.
Roadmap risk
Knowing where trust broke was not enough. One decision then removed every shortcut for fixing it.
05The turnIn the scene: no shortcut
Paid for, not earned.
I raised the distinction: a prepaid offer cannot behave like a reward. The loyalty product manager and the transactions product director agreed.
If it were a reward
Crown Rewards patterns and points
A place in the rewards tab
Every shortcut through loyalty
Because it is paid for
Its own identity: a Prepaid tag
A dedicated flow and a category free to grow
The whole post-purchase experience, designed from nothing
Ruling out loyalty said what not to build. The three dips said where to build.
06The designIn the scene: the path
One path and no dead ends.
A dedicated path from the ad to the restaurant counter, with an answer at each of the three dips. The screen after payment carries the most.
Dip 1 · what’s the catch?01 · The ad
The saving, not the price, leads: franchisees told us guests rarely know menu prices.
Dip 1 · what’s the catch?02 · Offer detail
The deep link resolves to the exact offer. Terms sit on the purchase screen.
Dip 2 · did I get it?03 · Purchase complete
“Saved to Offers” is the whole trust fix: it names where the money went.
Dip 2 · did I get it?04 · Stored in app
A Prepaid tag and a countdown, not a rewards badge.
Dip 3 · will they accept it?05 · Redeem
QR first, cashier code as fallback, because POS varies by franchisee.
Support tool
Support can see it, not edit it.
Until one flag is the single truth across POS and loyalty, a hand edit would create a second one.
Support · Orders tab
Support · Loyalty tab
The flows were clear. Keeping them shippable took a different discipline.
07The disciplineIn the scene: held back
22
Held out of the MVP
Every stakeholder wanted an MVP from the first call. If a feature needed structural change to the codebase before we knew guests wanted prepaid at all, it waited.
IA and navigation
Dedicated Prepaid tab
In-app Transactions hub
Unified Orders and Loyalty tab
Cart and payment
Mixed cart
Cash payment
Intermediate cart page
In-store purchase
Platform readiness
Auto-select nearest store
Map auto-refresh
Participating-stores-only view
Signed, expiring deep links
POS-sourced price
Refunds and support
Partial refunds
Redemption refunds
Support Tool write actions
POS and TLOG deep links
UX enhancements
Repeat customisation sheet
Smart counter UI
Order number on success
Sanity-driven success art
App-wide title-casing
Advanced CRM nudges
Six unready systems, three moves.
Record 03 showed where each system stood. Rather than rebuild any of them, the MVP got each one to yes with one of three moves.
Reuse
Borrow what already works.
Loyalty and offers engine
Prepaid redeems as a tagged zero-price item in the Offers tab.
Specify
Write down what was missing.
Ads and attribution
Campaign parameters captured on first entry, kept 24 to 48 hours.
CRM
Expiry events at 3 days, 1 day and day 0, specified in the event map.
Constrain
Narrow it until it is safe.
Payments (PSP)
Separate cart and checkout; login mandatory.
Deep links
Ad-driven deep links only; signed, expiring links deferred.
POS
QR first, cashier code as fallback, one market.
Three pieces of data that had to survive every handoff
Drop any of them and the guest sees the wrong offer, pays into the wrong account, or never gets a reminder.
Field
Travels through
Why it matters
offer_id
Ad → deep link → payment → loyalty
Lose it and the wrong offer loads.
user_id
Payment → loyalty
Binds the payment to the wallet the offer lands in.
expiry
Loyalty → CRM
Every reminder depends on it.
Twenty-two things waited so that one could ship.
08The resultIn the scene: rolling out
Pilot rolling out in the Netherlands.
Exactly as scoped: one market, one meal, one flow. Purchase, entitlement and redemption share one ID in the event map I wrote in August 2025, so the business will see who came back to eat, not just who bought.
What the pilot will check, moment by moment.
At each moment of a guest’s journey, one question, each read from a signal in the tracking plan.
Buys
Sees the ad, pays today
Will guests pay for a meal they can't eat straight away?
Read from purchases completed.
To be measured
Do new and returning guests want different things?
Read from ad to purchase, by account.
To be measured
Waits
The meal sits in Offers
Does a reminder bring them back before it expires?
Read from near-expiry meals redeemed after a nudge.
To be measured
Eats
Redeems in the restaurant
Is redeeming in the app easier than at the counter?
Read from redemptions by restaurant and channel.
To be measured
Comes back
Buys again, with more choice
Would a personalised offer sell better?
Not testable yet: the pilot sells a single meal.
Next phase
What the dashboard reads · designed in the event map · values stay with RBI
Acquisition
Landing → purchase click → success and time to convert
Post-purchase
Redeem-now tap rate and days to first redemption
Redemption
Redemptions per entitlement, by store and channel
Lifecycle
Near-expiry exposure to save rate and breakage by campaign
No numbers yet: the pilot is still rolling out, and when they come they stay with RBI. This is how it will be measured.
+Alongside the discovery
Two more pieces from the same remit.
Prepaid was one of four workstreams. These two ran alongside it: one made a brand-new Android feature designable, the other turned a one-off campaign into a model the business can reuse.
Android · live update notifications
No references yet, so I built some.
I supported the designer working on Burger King's Android live update notifications, a feature so new that few apps had adopted it.
01
The gap
Android's own documentation didn't make clear how live updates behave, and there were hardly any real-world references to learn from.
02
The testbed
I built multiple quick-service scenarios, such as order placed, being prepared and on the way, in the Android platform samples app using Claude Code, and ran them on Pixel emulators in Android Studio.
Capture 02
03
The guide
I compiled what the emulators showed into documentation, so the designer could design for every use case, layout and language with confidence.
Capture 03
02Scenario running on a Pixel emulator · lock screen03How a state really renders · notification drawer
Dragon Ball Z · app takeover
A takeover model, not a one-off.
We analysed the US team's SpongeBob implementation, defined a tiered takeover model and shipped it as a Sanity-powered Dragon Ball Z takeover across the guest app.
Before
Hard-coded per campaign
One market (US)
One campaign, SpongeBob
After
Configurable via Sanity CMS
Multi-market ready
Reusable across campaigns
Light
Theming, tiles, offer art
Shipped
Medium
Surface takeover, entry points
Shipped
Full
End-to-end brand world
Not yet
Three takeover intensities. Dragon Ball Z shipped at Light and Medium. Each tier is a fixed cost the business can choose from.
