An ambient light that turns CGM data into color.
Glowcose is the most important project I’ve worked on. It was a real, tangible problem for my wife and me at home and it’s turned into a product used by thousands of people. My wife is type-1 diabetic and in 2016, during her pregnancy, she was keeping her blood glucose lower than usual by recommendation, which also meant a much higher risk of hypoglycemia. I was setting alarms in the middle of the night to check on her without waking her, struggling to get back to sleep, and doing that fun daytime thing where you realize you haven’t checked in for an hour and your brain immediately panics and assumes the worst.
The first version was… scrappy. A Wi-Fi module and a few LEDs crammed into an IKEA kids’ lamp on our nightstand. It worked a lot better than it had any right to and we used it for years before starting Glowcose.
Purposefully ambient
Simple and present is the whole idea behind Glowcose. It takes CGM data and turns it into color, so anyone can understand what’s going on without picking up a phone or trying to discern a number from afar. “Ambient” has always felt like the right word because it stays in the background until you need it, then gives you useful information in half a second.
Color ended up being the key interaction decision. Glowcose maps glucose values across a wide color range, which gives users a quick intuition for where things are and where they’re heading without forcing them into the emotional weight of a specific number every time they look over. For a tired parent or partner, color is easy and chill and we love that about it.
One of my favorite design details is the dedicated white channel. If the data is stale or the network is down, the device turns white. Dedicated white LEDs (not the sum of red, green, and blue channels) are important to help ensure it’s as accurate as possible. The fun, colorful display is only useful if you can trust it, and white makes it immediately obvious that it’s not showing current glucose data.
From end to end
Glowcose has been ambitious in its technical breadth. On the mechanical side, Glowcose is fairly simple. It’s a handful of small injection-molded plastic parts and a translucent silicone cap for the LEDs to shine through and diffuse. A button on the back handles changing brightness and reconnecting to the self-hosted Wi-Fi access point for configuration. After the initial run, it ended up with a small stick-on silicone pad on the bottom and a steel weight to help keep it oriented when plugged in because it’s very light otherwise (pun not intended, but I’ll take it).
In the center of the hardware is an Espressif Wi-Fi module. It came with a pre-certified radio path, which saved a decent amount of compliance pain. The dual-core device helps keep the networking and LED behavior from stepping on each other. I do wish 5 GHz Wi-Fi were more readily available in low-cost MCUs, though.
On the software side, the initial intent wasn’t to build a web app for Glowcose, but very early on we realized a lot of users had to pay for a third-party service to host software to access their CGM readings. It boiled down to this: if we could own more of that experience ourselves, we could make it simpler and cheaper (free) for everyone. The early cloud services largely ran on TypeScript and React for device configuration and management.
On the surface, the technical challenge is straightforward, but it gets surprisingly hairy, surprisingly quickly. One thing I think we’ve done well with Glowcose is metering complexity as we scaled. Early devices were as simple as we could reasonably make them. Wi-Fi provisioning used a self-hosted access point, which made setup possible from any device (laptop, phone, etc.) and removed the need for a mobile app. It was very much the right choice at the time. We launched with support for the most common CGM first, which kept the focus on reliability. Early OTA was user-driven: the user opened the AP and chose to upgrade the firmware. This choice saved an immense amount of backend effort, at the very real cost of asking users to trigger the update themselves. Not the best experience for the less tech-savvy among us, although I stand by this being the right choice early on.
We’ve since built out much more infrastructure. Our backend is now largely .NET and a fair bit more robust. We’ve also grown the team a bit, and the help with development and reliability has been very welcome. Analytics and observability have been areas of constant improvement. Device management and OTA have made solid improvements and will likely continue to be areas of interest as we push to make the user experience as smooth and enjoyable as it can be.
Now that Glowcose has grown past 10,000 users, the engineering story is still a lot of the same themes (just a bit louder). Reliability, cloud infra, me complaining about AWS costs, OTA, device management, and third-party API changes are the bulk of the technical effort. Business and support are the other large parts of the work, and I love those too. Getting Glowcose into the real world and scaling it to a significant number of users has been hugely rewarding and an equal amount of work.
The best measure of all that work is what customers have written about it.
