Turning restaurant surplus into a two-sided marketplace
Wellbuy sold irregular produce and had few users. Leadership asked me to redesign the app. I pushed for user research first, then planned and ran it. The research pointed to a more frequent problem: small restaurants had unsold food every night. We rebuilt Wellbuy as a marketplace for that food, and I designed both sides.
Wellbuy was later acquired by Last Order, another company in the food-waste space.
What I owned
I made the case for research before the redesign, then planned and ran it. I facilitated the workshop where the team chose the new direction, worked with the PM on the two MVP tests, and designed the customer app and the restaurant owner app. I worked with 2 other UX designers, 2 engineers, and a PM.
Plan, recruiting, 50 owner interviews, a 107-person survey, and synthesis.
Facilitated the workshop that set the new direction, and scoped it to unsold food.
Flows, wireframes, and final screens for customers and restaurant owners.
The brief was a redesign. The product had no validated problem.
“Redesign the entire app to increase users and revenue.”The brief I was given
Wellbuy sold fruit and vegetables that markets rejected for their shape. It had few users and low revenue.
The produce direction had been chosen without talking to customers or sellers. A redesign would have polished screens for demand no one had tested.
I asked how the direction was chosen, did a short round of desk research on my own, and brought leadership a stronger opportunity and a research plan.
Leadership agreed to research users before any redesign, and I owned the research.
The original idea was solving the wrong problem
Industry data showed that 70% of surplus food comes from small restaurants, so I focused the research there. Owners declined interviews at first. We ate at their restaurants as customers until they agreed to talk.
Surplus was predictable, not accidental.
36 of 50 owners cooked more than they expected to sell, on purpose, and then had food left at closing. Owners told us: “It is better to have surplus food than to run out of food.”
I scoped the product to selling what was left at closing, not to changing how much kitchens cook. Owners saw the extra food as insurance, so we did not try to change that.
Students wanted a lower price without guessing about quality.
In a 107-person survey, university students were the most willing to buy discounted end-of-day food. Follow-up research with students pointed to three needs: low price, fresh food, and pickup near campus.
Students near one university became the first market. Price, freshness, and pickup time had to be visible before a student opened an item.
Creating value for both sides
Neither side works alone. Restaurants will not list without buyers, and buyers will not come back without listings.
- Revenue from food already cooked
- Little extra work near closing
- Simple pickup and payout
- Shows each restaurant’s surplus to nearby buyers
- Takes payment and settles with owners
- Needs enough restaurants and students in one area
- Nearby options, found fast
- Confidence in the food
- A clear pickup time
The pilot started around one university, where students and restaurants were close together.
Would customers buy, and would restaurants join?
Before development, we tested the two assumptions that could sink the business: demand and supply. Follow-up interviews with students and owners then shaped the design changes below.
The MVP covered one transaction and nothing else
I mapped the full customer flow, from sign-up to reviews, then cut the MVP to the smallest set that let both sides complete an order.
- 01Find nearby restaurants
- 02Browse clearance items
- 03View item details
- 04Order and pick up
- 01Post surplus
- 02Receive the order
- 03Set a pickup time
- 04Get paid
- Browsing by restaurant
- Item options
- Restaurant details and reviews
- Location switching and filters
- Promotions
Most deferred features came back after the pilot, when testers asked for them.
What the pilot changed
Interviews after the pilot showed where the MVP fell short for students. Each change starts with what we heard.
Let students choose the restaurant first.
- Restaurant cards with discount, rating, distance, and pickup time
- Location setting, so students can switch campus or area
- Cuisine tabs and a distance filter
MVP: dishes from many restaurants in one list.
Final: restaurant cards with discount, rating, and distance.
Make a discounted meal feel like a normal order.
- A restaurant page with clearance items above the regular menu
- Original and discounted price for each item
- Required and optional choices, such as egg style and toppings
- Restaurant details and reviews in their own tabs
MVP: one item, fixed price and quantity.
Final: clearance section in the menu, and item options.
The shipped experience
Two apps on one transaction. A customer’s pickup time is the owner’s prep commitment, so I designed both flows together.
Built for a quick, time-limited decision near campus.
Owners handle these orders near closing, alongside regular service. I kept each order to a few taps: review it, set a pickup time, and mark it picked up.
A later Wellbuy feature extended closing-time deals from single restaurants to multi-store brands, with the same pickup flow.
What happened
“Wellbuy offers convenience by enabling me to quickly locate discounted restaurants near my area. I am satisfied with the affordable pricing, ease of use, and high quality of the food provided!”
“I was satisfied with earning additional revenue from selling surplus food and preventing no-shows by utilizing the platform.”
Wellbuy was later acquired by Last Order, another company in the food-waste space.
What I still use from this project
The brief asked for better screens. The larger gain came from asking what Wellbuy sold, and to whom.
Owners said no until we had eaten at their restaurants. That trust mattered later: 12 of the same owners joined the pilot.
A customer’s pickup time is an owner’s prep commitment. The two apps only worked when I designed them together.