She kept asking me to hand her the phone, so I built something.

The problem was almost too small to call a problem.

At night, my girlfriend would sometimes ask me to hand her phone over so she could check her glucose. The information was already there. It just was not visible when she needed it.

That small inconvenience stayed in my mind because it was ordinary, specific, and something I could work on. Reaching for a phone, unlocking it, and checking the screen put several steps between a simple question and information that already existed. I started wondering about those steps.

I did not need to invent new information. I needed to give information we already had a better place to live. That distinction gave the project a clear starting point: make the number visible from bed, in a form that belonged in the room.

What if the number was simply part of the room?

That question turned into DexcomFrame: a Raspberry Pi, a touchscreen, a frame, and software bringing the pieces together. The original idea was easy to describe. Building it meant working through the distance between putting information on a screen and making that screen useful in a bedroom.

Readability became a practical design question. The display needed to work from bed, with the number given enough space and emphasis to find quickly. A layout that looked good up close still had to make sense from across the room. The place where it would be used mattered.

The frame was part of the interface

The physical build gave the idea its shape. A seven-inch touchscreen, Raspberry Pi, wiring, and shadowbox frame all had to fit together. The enclosure was part of making the display feel like an object that could stay in the room, with the hardware supporting its purpose.

Software projects can keep growing inside a browser window. This one also had a physical boundary. The screen size and the frame made the choices concrete: what deserved space, what could stay in the background, and what would still be legible at a distance?

That connection between the object and the interface is one of the things I like about DexcomFrame. The project asks me to think about code, layout, and physical fit together. Each decision has to come back to the same use: a display someone can glance at from bed.

A bedroom gives the design a different set of priorities

The number needed to remain the priority. Graph history, weather, and changing scenes could add context, but they had to earn their place around it. Adding another feature was only useful if the display stayed easy to understand. That gave me a way to question my own additions.

Nighttime behavior mattered just as much as the daytime layout. I wanted the display to be quiet at night, with changes in state that were distinguishable without making the room feel chaotic. Brightness, contrast, and visual emphasis became parts of the same problem.

The goal was to make it feel like an appliance: understandable, predictable, and comfortable to leave in place. Getting a screen to show a number was one step. Iterating on how it behaved in the room gave the project a much more useful standard to work toward.

Engineering does not have to stop when the workday ends.

One of the things I like most about engineering is that it becomes a way of noticing the world. DexcomFrame started with paying attention to something small enough to overlook, then asking whether I could make that moment easier. That is still the part of the story I care about most.

A roadway problem and a bedside display are very different things, but the instinct underneath them can be similar: notice friction, understand the system, make something, and revise it when it falls short. The setting changes; the habit of asking useful questions carries over.

A clear, specific problem gives a project something real to test against. For DexcomFrame, that question has always been simple: can the information be easier to see where it is needed? The hardware and software grew out of that moment, and that moment still explains why I wanted to build it.