Problem
TGTG's model is built on open discovery. You open the app, see what's nearby, and buy. That simplicity is the product. Corporate canteens broke that model.
A large company with an internal lunch kitchen produces surplus food every day - but they can't list it publicly. Their bags are for employees only. The sales team was fielding requests from companies that wanted to reduce food waste but had no way to participate without exposing their canteen to anyone with the app.
The challenge wasn't just adding a feature. It was designing a private access layer that worked seamlessly for employees, was simple enough for canteen managers to own themselves, and didn't surface a confusing new concept to the millions of users who'd never need it.
The challenge: a private access layer that doesn't complicate the experience for the millions of users who'd never need it.
Design decisions
A printed poster, not an admin invite system
The instinct for "employees only" access is an account-based model: link your work email, verify your employer, sync with HR. We didn't build that.
Instead, we put distribution entirely in the partner's hands. Canteen managers set their own access code via the partner web app, then generate a branded poster with that code and a unique QR code. They print it and hang it in their canteen. The QR deep-links into the app and auto-unlocks the partner - or sends first-timers to the App Store. No TGTG ops involvement, no employer integrations, no employee lists to maintain. The canteen itself becomes the verification mechanism: if you see the poster, you work there.
iOS camera recognizes the QR as a TGTG deep-link and surfaces the app banner directly.
A visible entry point in the app, not QR-only
We added Hidden Stores to the More menu in the tab bar rather than making it only reachable via QR.
The reasoning was sound: an employee who heard about it from a colleague but didn't have the poster nearby should still be able to find it and enter a code manually. QR-only would have created friction for exactly the users we wanted to reach.
What we didn't anticipate was the other side of that decision. Putting it in the main nav made it visible to every user - including the vast majority who'd never use it. That discoverability was the right call for employees, but it's also what set up the naming problem in decision 03.
"Hidden Stores" - a name that worked against us
We debated names for this feature more than almost anything else in the project. We landed on Hidden Stores - accurate, slightly playful, and honest about what it was: partners hidden from the main feed.
It turned out to be too interesting. The word "hidden" read as exclusive rather than functional - it implied there was something to discover, not just a tool for a specific group. Reddit threads appeared. Support messages came in from regular users with no employer canteen, curious about codes and "wizardry" that had no relevance to them.
User testing the name before launch would have surfaced this. We shipped on instinct and found out through support volume and community posts.
Designing both sides independently
This was a consumer feature and a partner feature at the same time. Employees needed a frictionless unlock flow that required almost no explanation. Canteen managers needed a setup experience simple enough to own without support.
Keeping the two flows entirely separate - partner setup in the web app, consumer unlock in the mobile app - was the right call. But the two-sided scope was consistently larger than it first appeared. Every design decision had two implementation surfaces, and user needs that felt simple on one side often created constraints on the other. What started as a consumer feature with a small partner component was closer to two parallel projects sharing a data model.
My role
I was the Senior Product Designer on this project at Too Good To Go, working across both the consumer app and the partner web app. I owned the end-to-end design: the consumer unlock flow, the code entry screen and explainer, the partner setup experience, and the poster template that partners generate and print. I worked closely with engineering, the sales team, and a small set of early canteen partners who helped validate the setup flow before launch.
Reflection
Two things I'd do differently.
The naming deserved a test before launch. We made a judgment call and it was wrong in a specific, measurable way - support volume and Reddit threads told us so. One round of user testing on a shortlist of names would have cost a week and saved ongoing confusion. It's a cheap lesson, but only if you actually take it.
The two-sided scope also caught us underestimating. Features that live on both the consumer and partner sides of a marketplace carry hidden complexity. I'd frame and resource it differently now - scope it explicitly as two parallel workstreams from the start, not a primary flow with a secondary component bolted on.
I've stumbled across on my profile, a section that says Hidden Stores?! Is there a code for this wizardry and is it worth going to great depths looking for it?
My university uses a hidden store so students can access it and not the wider public
What's the code sir!?
Apparently it's for certain corporate partners of TGTG. They allow employees of the corporate partners to have access to certain locations not available to the public