A shared fridge list gives the PaperMono a daily job
Add milk from your phone, and the same list can appear on the e-paper screen attached to your fridge. PaperMono Shopping List combines firmware for M5Stack's PaperMono with a FastAPI server and a browser interface. Aisles appear in the order you walk through the shop, and previously entered names become suggestions. The appeal is a household list you can glance at without opening a phone, with the phone still available for adding groceries elsewhere.
The repository we checked out occupied 1.3 MB across 96 files, and our measured Python project was the server under server/. The hardware half is C++ firmware using PlatformIO. This separation makes the recommendation quite specific: try it if you already want a PaperMono project and are willing to maintain its server. If your only goal is sharing groceries between phones, the physical device and its firmware introduce work you can avoid.
What happened when we ran it
Our sandbox installed commit d162a9b in 13 seconds, adding 74 packages and using 103 MB on disk. The build passed in 2 seconds, and pytest passed all 120 tests in 7 seconds, with 0 failures. We ran the server project on October 15, 2026, in an unprivileged Debian container with 3 CPUs, 8 GB of RAM, and Python 3.12. No secrets were available to the process.
Pip-audit reported 0 known vulnerabilities, and the scan found a Dockerfile, a tests directory, and 1 CI workflow file. That is a reassuring result for the server path we exercised. It does not measure the touchscreen, device battery, physical flashing, or the quality of aisle suggestions from Claude. A green Python suite is a reason to try the software, while the hardware and network choices still decide whether your household will want to live with it.
The server has no login, so remote access needs protection
The server security notes explicitly say anyone who can reach the API can read and change the list. Keep the device on a trusted LAN address. If you want to use the web interface away from home, the documented route is a proxy or tunnel that authenticates people first. The device cannot complete an interactive browser login, so the documentation separates its local connection from the protected remote entrance.
A successful 13-second install does not configure that boundary for you. You also need persistent storage for the SQLite database and a backup routine. The server guide documents the database location, a safe SQLite backup command, and both systemd and Docker deployment. Set the shopping-list timezone explicitly for scheduled syncs, especially in containers using UTC. Those are ordinary server chores, but they are still chores attached to buying milk.
Changing Wi-Fi requires new firmware
The README says only the PaperMono C153 has been tested, and Wi-Fi credentials plus the server URL are compiled into the firmware. There is no on-device Wi-Fi setup. Moving to another network therefore means changing configuration and rebuilding the device image. Before the first flash, the firmware guide tells you to save the device's flash because it contains factory calibration data. Treat that backup as part of setup, before you overwrite anything.
Our 2-second successful build belongs to the Python server path, so it cannot estimate preparing or uploading firmware. The repository documents PlatformIO and a container-based firmware route, plus a browser flasher. Those options make the process more accessible without removing the need to understand which image you are writing. This is appropriate for someone comfortable recovering a device over USB. It is a poor present for someone expecting to change a Wi-Fi password through a settings screen.
Offline edits survive, with limits around sync
The device caches the list and queues edits on flash, allowing use without a live connection. The design notes document concrete compromises: syncing blocks the interface, retried adds can duplicate an item, and pending items cannot be ticked until they receive a server ID. Last-write-wins handling also means simultaneous phone and device edits have no conflict-resolution screen. These are understandable choices for groceries, provided you know what happens during a connection failure.
The 120 passing tests do not erase those documented behaviors. Nor would I use the old design-notes claim about missing light sleep as a current limitation: the README and dedicated firmware guide describe light sleep, and October activity includes that work. The documentation has drifted between pages. Read the specific operating guide alongside the short limitations list, and avoid treating every historical note as a description of the current firmware.
Claude sorting is optional and sends item names outside your server
The basic list works with SHOPPING_LIST_CLASSIFIER=none, which is also the Docker default. Enable the classifier and the server invokes the Claude Code CLI with new item names and aisle names. You must authenticate that CLI through an API key or the documented subscription-token route. Manual corrections stay in the catalog, so you can teach the right aisle yourself. For a household that prefers local-only data handling, leave classification disabled.
The 103 MB environment from our sandbox does not establish the behavior of an authenticated classifier. The docs also warn that enabled OpenTelemetry logging includes item names, another choice to make deliberately. GitHub showed 205 stars, an October 6, 2026 last push, and an October 11 open documentation PR. The latest-release endpoint returned no release. Recent work supports calling this a maintained personal project, while the author explicitly says it runs on a device at home.
KitchenOwl is the better comparison if shared grocery lists and recipes on phones are the whole job. Grocy suits a household that also wants inventory management. I would choose PaperMono Shopping List when the fridge display is the reason for the project and someone in the household will own firmware recovery and the server. Before flashing, save the factory image. Before opening remote access, put authentication in front of the web interface.