I joined to help with the software. I ended up wiring the bins too.
A reusable-cup system that pulled me from cloud software all the way down to Raspberry Pis, RFID readers and motors.
How I got involved
Loopack started as an idea a friend had been carrying since university. He already understood the mechanical side of the product: 3D modelling, 3D printing, physical design and the entire business idea.
What he needed was someone who could make the technical system actually work end to end, so I joined initially to help with the software while he focused more heavily on the mechanical and business sides.
It did not stay “just software” for very long.
From RFID tags to the cloud
Each reusable cup carried an RFID tag. The smart bins had to identify the cup, trigger the mechanical opening system, register the return and synchronize that event with the rest of the platform.
I ended up working across that whole chain:
- Raspberry Pi software;
- RFID readers;
- motors and electronics;
- wiring and GPIO;
- device-to-backend communication;
- databases;
- backend infrastructure;
- the user-facing application.
For once, debugging meant checking both the code and the cables.
Garage mode
Much of the early product was built exactly as it looks in the photos: Raspberry Pis, loose wires, RFID boards, motors, glue, 3D-printed parts and a lot of iteration.
There was no clean separation between hardware and software. If the bin did not open, the problem could be a motor, a GPIO pin, the RFID reader, the application logic or the backend. Very efficient way to make every bug slightly more suspicious…
Turning the prototype into a system
As the project evolved, we also started restructuring parts of the software and infrastructure. We moved away from a very basic backend setup and introduced a more structured stack, including Supabase.
I also worked directly with an engineering student who joined the project, building parts of the system together and gradually transferring context and ownership.
That was important because by then the project was becoming more than a bench prototype held together by code, wires and optimism.
The moment it became real
The first meaningful real-world test was a month-long pilot in one of the engineering faculty departments, connected to an existing coffee vending area.
Technically, it worked! Cups could be identified, returned and tracked through the system in a real environment instead of on our workbench. We later tested the concept again at a university event with heavier usage.
Those pilots were the point where the project stopped feeling like an electronics prototype and started behaving like a system people could actually use. And, importantly, one that still worked when people who had not built it started touching it.
Why I left
Around the same time, Full Belly was starting to show enough potential that I wanted to focus my time there. I was able to hand over the technical context and much of the work to the engineering student I had been working with before moving on.
After I left, Loopack went on to run its largest public test yet at a major academic event, and it was a nice confirmation that the thing had outgrown the workbench!
What I learned
Software gets very real when it controls something physical
A bug in a web app is annoying, but a bug in a system that has to read a cup, move a motor and register an event gives you a very different relationship with debugging.
End-to-end ownership changes how you think
Working from electronics and device code all the way to backend and UI made the system boundaries much more tangible.
A prototype only becomes a product when it survives the real world
The important milestone was not getting the RFID reader to work on a table. It was seeing the full system operate with real users, real usage and all the messiness that comes with both.