All Projects
Pico WFastAPIDuckDBMicroPythonHardware

Desk Gadget Renewal Display

A Raspberry Pi Pico W and FastAPI desk display that showed a focused renewal count from a read-only DuckDB source without exposing record-level data.

Archived3 min readJune 2026

Desk Gadget was intentionally tiny: one count, one display, one purpose. The public-safe code is available at UwUGreed/desk-gadget.

The idea was to put an operational signal on a physical desk display instead of burying it in a dashboard. The first version showed renewal volume for a producer over a configurable time window. It was not trying to become a full reporting suite. It was a small object that answered one question at a glance.

The Architecture

The system had two halves.

The server side was a FastAPI app that opened a local DuckDB database in read-only mode and returned a small authenticated JSON response. The hardware side was a Raspberry Pi Pico W running MicroPython, connected to a simple I2C LCD.

The data flow looked like this:

DuckDB view
  -> read-only FastAPI endpoint
  -> Pico W over Wi-Fi
  -> 16x2 LCD display

The Pico never received database credentials. It only knew the API URL and bearer token.

Security Shape

The project was small, but I still treated it like internal infrastructure.

The API returned aggregate counts only. No client names, policy numbers, premium, commission, or record-level detail went to the gadget. The endpoint required a bearer token, disabled client-side caching, and defaulted to localhost binding unless explicitly configured for the LAN.

That gave the build a clean boundary:

For a physical device sitting on a desk, that mattered. Convenience should not mean leaking the database to a microcontroller.

The Hardware Layer

The Pico W connected to an HD44780-compatible LCD through an I2C backpack. The MicroPython program handled Wi-Fi connection, API fetches, error states, and display refreshes.

The failure modes were deliberately boring. If Wi-Fi failed, the screen showed a Wi-Fi error. If the API failed, it showed an API error. If the database query failed, the server returned a small error status without exposing internals.

That made the gadget useful in the real world. It did not need a monitor, SSH session, or dashboard open all day. It just needed to keep a small operational number visible.

Why It Matters

This project is a good example of building at the right scale.

Not every business tool should become a web app with logins, charts, filters, roles, and dashboards. Sometimes a workflow needs one quiet signal in the right physical place.

Desk Gadget was that: a small hardware interface on top of a carefully bounded data path.

Back to projectsDiscuss this project →