1. Project Title
Still Good
A campus board where a canteen posts the leftover portions it is still serving, and a student nearby claims one portion before the counter throws them out.
2. Select Your Theme
Primary theme: Eco-Friendly & Sustainability
The purpose is waste reduction: cooked portions that are still safe to serve should be eaten instead of discarded.
The idea also touches two other themes, but they are not the primary purpose:
- Logistics & Supply Chain. The only "shipment" is a short walk to a counter that is already open. The design is about the last hour of inventory, not a new delivery network.
- Social Impact & Community Innovation. A posted portion can be a cheaper meal for a student who is already on campus. That is a side effect of wasting less food, not a separate charity program.
3. Problem Statement
What is the problem?
University canteens cook for a rush, then keep unsold hot portions in the warmer until the counter closes. After that window, the food is thrown away. It cannot honestly be sold as tomorrow's lunch. In the same hour, students on the same campus want a meal and do not know which counter still has food.
The missing piece is not another kitchen. It is a clear, portion-counted notice in the last part of the afternoon: what is left, how many portions, until when, and where to pick it up.
Who is affected?
- Students who would eat the food if they knew it was still being served, including students looking for a low-cost meal between classes.
- Canteen staff who already know the trays are going to waste and have no simple way to tell the campus, other than hoping someone walks past.
- The campus, which pays for food that is cooked and then discarded, and which reports food waste without a last-hour way to reduce this specific stream.
Why does it matter?
This waste is concentrated, predictable, and close to the people who could eat it. The portions are already cooked. The eaters are a few minutes' walk away. The holding time is short, so a fix has to be a notice, not a new supply chain. Cutting this stream does not solve all campus food waste, but it is one of the few streams a student and a canteen counter can act on the same day.
What are the current limitations?
- A student only learns what is left by walking to the counter. If the tray is already empty or the window has closed, the trip was wasted and the next student still does not know.
- Staff will not manage a chat group, answer repeated messages, or negotiate prices in a thread during close.
- A commercial surplus-bag app is built for a shop that can pack a surprise bag and sell it later through a payment platform. A campus counter needs an exact dish, an exact count, and a pickup inside the holding window it already uses.
- Giving hot food to an outside charity needs time, containers, temperature control, and a recipient who can arrive before the food is unsafe. Many counters close before that can be arranged. This proposal does not try to replace food-donation rules or claim to be a donation scheme.
Why existing approaches fail to solve it effectively
- End-of-day discounts only help people who are already at the counter.
- Group chats have no live portion count, no hold, and no record. Two people can be told the same last portion.
- Surprise-bag apps hide the dish and add a payment company the canteen may not want for a few portions.
- Cooking less is the right long-term control, but a canteen that under-cooks runs out during the rush. The board only deals with what remains after the rush, which staff can see.
No count in this proposal is a measured result from a Hong Kong canteen. Those numbers have not been collected. The problem statement is a design observation, not a field study.
4. Proposed Solution
Still Good is a proposed campus notice board, not a deployed app and not a delivery service.
A canteen posts each leftover dish it is still willing to serve: dish name, number of portions, pickup window, counter, and either "free" or a reduced price paid at the counter in the normal way. A student who can walk there claims one portion. The claim holds that portion for a short time. The student collects it at the counter with a short code. If they do not come, the portion goes back on the board until the window ends. When the window ends, the canteen discards what is left, exactly as it would have done without the board.
How it would work
- After the lunch rush, or in the last part of service, one staff member posts a dish. Suggested fields: canteen, dish name, portions left (a whole number), pickup start and end, counter name, price ("free" or a cash price), optional allergen note, and the time of the post.
- The public board shows only that campus. Each card says how long the walk is in plain words the canteen writes once, such as "about five minutes from the library." There is no map service and no paid API.
- A student claims one portion. The board shows a four-character code and a hold, proposed as 15 minutes or until the pickup window ends, whichever is sooner.
- The student shows the code at the counter. Staff mark it collected and hand over the portion. Any money is paid there, with the canteen's existing cash or Octopus flow. The board never takes payment.
- If the hold expires, the portion returns to the count. At the window's end time, the card closes. Staff do not keep food longer because a card is open.
- If a walk-up customer buys a posted portion outside the board, staff reduce the count. The board is a shared tally, not a second stock system.
Who would use it
- One canteen staff member at close, for about two minutes per post.
- Students already on that campus who can arrive inside the window.
- Later, a campus sustainability office could read the weekly totals. They would not run the counter.
What makes it different
- It counts portions of a named dish, not a mystery bag.
- It does not move food off campus, extend holding time, or create a delivery route.
- It does not need a payment company, a map API, SMS, or push notifications. Version one is a board the student refreshes.
- It can start as a paper sign or a shared spreadsheet. Software is optional. The deck is the product at this stage.
What this submission is not
No app has been built. No canteen has agreed to a pilot. No student has claimed a portion. Screens described below are a specification for a later build, not a product that exists.
5. Innovation & Uniqueness
The innovation is a process and a service rule, not a new technology.
Most food-saving products try to add a market: new users, packaged bags, delivery, or an outside platform. Still Good adds a last-hour tally to a counter that is already open. The new rule is simple: do not advertise food the counter would not still serve to the next person in line, and do not let the advertisement keep food past the discard time.
What is unusual in combination:
- Portion truth. The public number is the number staff can still hand over. A claim is a temporary hold, not a promise that food will be saved for the evening.
- No new money rail. Price, if any, stays at the counter the canteen already trusts. That removes a common reason small counters refuse surplus apps.
- No paid API and no lock-in. Walk times are typed once. Notices live on a page or even a sheet. A campus can leave whenever it wants.
- Staff cost is the design limit. If a post takes more than a couple of minutes, the design has failed, even if the interface looks polished.
- Language. The board says "still being served," not "waste" or "leftovers for the poor." Staff are more likely to post if the sign does not shame the kitchen.
The idea is deliberately small. A campus does not need a citywide food-waste platform to stop throwing out the last trays of rice and vegetables.
6. Supporting Materials
This file is the supporting material. It is a concept presentation: written sections plus a 10-slide script. It includes a process description, a field list, operating rules, a resource list, and an honesty check.
Not included, because they do not exist:
- A working prototype, wireframe file, or mockup image
- A filmed demonstration
- Market research with measured campus waste figures
- A financial model with real revenue
- A signed canteen partner
Those would be fabricated if they were added now. The rules warn that fabricated research and false claims can disqualify a submission.
Optional demonstration. No video, animation, or prototype is provided. The slide script is the visual walkthrough. Judges should treat it as a proposal.
Suggested first board, if a canteen later agrees (not built):
A view-only sheet or page with one row per dish:
| Field | Example (illustrative, not a real post) |
|---|---|
| Canteen | Campus canteen, counter B |
| Dish | Steamed pork with rice |
| Portions left | 6 |
| Pickup window | 15:10–15:40 |
| Where | Side window, not the main queue |
| Price | Free, or pay HK$15 at the counter |
| Allergen note | Contains soy and gluten |
| Posted at | 15:05 |
| Claim | One portion, 15-minute hold, code shown on the student's screen |
Operating rules that keep the board honest
- Post only food the counter would still sell or give to a walk-up customer.
- Never post after the canteen's own discard time.
- One active claim per person per window.
- No delivery and no off-campus pickup.
- The public link cannot edit the count. A separate staff link can.
- The board is not medical advice. The allergen line is whatever staff type, and it can be blank.
7. Project Presentation
Expected users
Primary user: the closer. One person on the canteen shift who can see the warmer. They need a post that is faster than walking the dining room to announce the trays.
Primary user: the nearby student. Someone who can arrive before the window ends. They need the dish name, the count, the deadline, and the counter. They do not need an account with a wallet. A display name and a claim code are enough for a first version. A university email could be added later if no-shows become a problem.
Not a user in version one: couriers, off-campus customers, and outside charities. Adding them would change the food-safety and liability story.
Implementation process
This is a proposed sequence. None of the steps has been started.
- This submission. A written concept only.
- Ask one counter, do not build first. Show the closer a one-page version of the rules and ask whether they would try a paper sign for three afternoons. If they say no, the project stops. A board nobody will update is not a pilot.
- Paper pilot, if they say yes. A whiteboard or printed card: dish, count, time. Students tell the counter they saw the sign. Staff keep a tally of posted, collected, and discarded. No app, no account, no payment change.
- Only if the paper sign is used: replace it with a view-only sheet or a small page the staff already know how to edit. Still no paid API. Still no in-app payment.
- Stop rules. Stop if staff say it slows closing, if students claim and do not come, or if anyone asks the board to hold food past the discard time.
A student builder could do step 4 alone after a canteen has asked for it. It should not be built before that conversation.
Resources required
- One student to write the rules, talk to one canteen, and keep the tally.
- One canteen supervisor willing to try three afternoons. Not yet identified.
- Staff time of about two minutes for each post, using a pen or a sheet.
- A free view-only document if the paper sign works. No server contract and no paid API.
- Existing counter payment if a portion is not free. The board does not add a payment provider.
- No new kitchen equipment, packaging line, fridge, or delivery budget.
There is no grant, sponsor, or campus approval in hand. Those are not claimed.
Potential challenges
- Food safety. The board must not become a reason to hold hot food longer. The pickup end time is the canteen's time, not the student's.
- Liability. The canteen still prepares and hands over the food. The board only publishes a count the canteen chose to publish. This proposal is not a food-donation license and does not ask staff to give food to an unknown off-campus group.
- No-shows. A 15-minute hold and a one-portion cap limit the damage. Repeated no-shows would mean dropping claims until the person is at the counter.
- Wrong counts. Walk-up sales can make the board lie. The closer has to be able to change the number in one tap or one pen stroke. If they will not, the board should not exist.
- Edit access. A public edit link would let anyone change the menu. The public view and the staff edit have to be different links.
- Shame and demand. Calling it "waste food" will discourage kitchens and can stigmatize students who use it. The public words are "still being served."
- Fairness. A free tray can be taken by the fastest phone, not by the student who needed the meal. Version one does not solve that. It caps claims at one and stays on campus. A needs test would be a different, more sensitive project.
- Allergens and diet. A short note is not a guarantee. Students with strict diets should not rely on it.
- Scope. Prep waste, cooking oil, and unsold packaged snacks are outside this design.
- Honesty of the entry. Submitting this deck as if an app were live would break the challenge's own rule against false claims.
Expected outcomes
These are outcomes to measure if a pilot happens. They are not results.
- A tally, kept by the canteen, of portions posted, portions collected, and portions still discarded.
- A record of minutes staff spent posting.
- A no-show count.
- A decision at the end of three afternoons: continue, change the rules, or stop.
A useful result is a smaller discard pile on those afternoons without a longer close and without food held past the safe window. A weak result is also useful: if students do not come, the campus should not build an app.
If the paper pilot is never approved, the outcome of this project is the design itself: a rule set another student or canteen can try without paying for a platform.
8. Optional Demonstration
No demonstration video, prototype, or animation is attached. There is no video. The ten slides are a separate concept presentation of a proposed design. They should not be read as evidence that a service is operating.
Log in or sign up for Devpost to join the conversation.