A Barcelona charity sends volunteers on regular walks to people living on the street. Along the way, people ask for things they need: a tent, a sleeping bag, trousers in a certain size. Every request goes into one shared Google Sheet, and the walk leaders use that sheet to decide what to bring next time.
The problem
The sheet works well on a laptop and badly on a phone, which is where walk leaders actually are. On a small screen, finding the open requests for tonight's route meant scrolling sideways through a wide table. Several people edit it at once. Some rows held three items in one cell, and nobody could tell at a glance what still had to be packed.
Replacing the sheet was not an option. Volunteers know it, it costs nothing, and many people rely on it. The volunteers needed a better way in, not a new system.
What we built
A small mobile web app that reads and writes the same sheet. It stores no copy of the requests: the sheet stays the only source.
- Requests by route, newest first, with large status buttons: open, at the local, delivered.
- A pack list per route. It shows only items and sizes, never names or places, and counts duplicates together, so "2× tent" is ready to copy into the group chat before leaving.
- Split combined requests. A row like "trousers 36/38, socks, bra" becomes one row per item, each with its own size and status.
- Not deliverable, with a reason. For example the person has moved on, or no longer needs it. The app never closes a request by itself. After three failed attempts on different days it only suggests it.
- WhatsApp and call buttons on open requests that have a phone number, with a pre-filled message in English and Spanish that names the item, never the volunteer.
- Dark mode, because many walks happen in the evening.
Keeping the sheet safe
Several people edit the sheet at the same time, partly in the app and partly directly in the sheet, so the app is careful about every change:
- Check before writing. Each change sends the row as the volunteer saw it. If someone else changed it in the meantime, the app refuses the write and shows the new version instead of overwriting it.
- Only changed cells are written, and the original request date is never touched.
- A header guard. If someone renames or moves a column, the app stops instead of writing into the wrong place.
- A change log records every edit and every refused conflict.
The result
Walk leaders now see their route's open requests and pack list on their phone in seconds, while everyone else keeps working in the sheet as before. Nothing had to be migrated, nobody had to learn a new system, and if the app ever goes away, the data is exactly where it always was.
What we took away
Sometimes the best new system is a better window onto the old one. When a spreadsheet is the thing people trust, build on it and protect it instead of replacing it.