I Built the App Ember Should Have Shipped
- Rich Washburn
- 21 hours ago
- 5 min read
I want to say upfront that "I built" is doing a lot of heavy lifting in that sentence.
What I actually did was look at my coffee mug, have a thought, type that thought into Glaze, and go do other stuff. About fifteen or twenty minutes later, I had a finished, working macOS application sitting in my menu bar. It connected to my Ember Mug over Bluetooth, showed me the temperature, and sent me a push notification when the battery got low. I'm not sure "I built" is even the right verb. But here we are.
If you've never used an Ember Mug, the short version is that it's a smart coffee mug with a heating element in the base and a Bluetooth radio in the mug. It keeps your drink at whatever temperature you set. It's genuinely great — I have two of them. I make coffee in mine when I don't have a microwave handy. Coffee packets, hot water, turn it up all the way, fifteen minutes later you're drinking coffee. Same for tea. I've done soup. The mug doesn't know it's not supposed to be that versatile.
The problem is the Ember app. It's a phone app. Which means to see your coffee temperature, you have to pick up your phone, unlock it, open the app, look at the number. If you're at a desk working, that's a completely broken workflow. Your attention is on the screen in front of you, not your phone. The mug is sitting three inches from your keyboard doing its thing and the only way to know if your coffee is hot or your battery is dying is to break your focus and reach for your phone.
Ember sells a premium product. I'd argue the lack of a desktop app is the biggest oversight in that product. It's been that way for years. At some point I accepted it as just a thing I had to deal with.
Then I started messing around with Glaze.
Glaze is an AI-powered app builder for Mac. You describe what you want. It writes the code, compiles it, runs it. I'd used it before for PromptPocket — a little floating text-node utility I use every day — and was still kind of stunned by how well that had gone. So I decided to try something harder. Ember Mugs use Bluetooth Low Energy and have a documented GATT protocol — specific UUIDs for temperature, battery, liquid state, push events. Real Bluetooth stuff. Not exactly a form and a button.
I gave Glaze the concept. Mug controller. Menu bar. No phone required. It figured out that its macOS WebView layer doesn't support Web Bluetooth, so it routed the BLE communication through a Python helper in the Node backend — `python-ember-mug` and Bleak, talking over newline-delimited JSON on stdio. All the temperature math ran in TypeScript with unit tests. The Python layer handled the actual Bluetooth reads and writes.
I didn't design any of that. I didn't specify any of that. I described the problem and it architected a solution.
Eighteen passing unit tests covering every edge case — temperature encoding and decoding, Celsius-to-Fahrenheit conversion, battery percentage parsing from hex, liquid state mapping. All green.
I went and did other stuff.
When I came back, I had a menu bar app. Coffee cup icon. Current temperature displayed next to it in real time. Click on it and you get the full panel: current temp, target temp, battery percentage, charging status, heating state. Preset temperature buttons. Custom temperature input with range validation. A button to turn heating off. Settings. An About card with my logo and a link to my site.
The icon changes color based on status. Red when it's at target temperature. Normal when it's heating. Gray when it's disconnected. You can tell what your coffee is doing without clicking anything.
Low battery notifications. When the mug is off its charging base and drops below your threshold — I have mine set to 30% right now while I'm testing, usually I'll run it at 20% — you get a real macOS notification. Sound, banner, the whole thing. Same kind of alert your calendar sends you. It fires once per discharge cycle, doesn't spam you, re-arms when you put it back on the base. There's also a critical alert at 5%.
No cloud. No account. No subscription. Your mug data stays on your Mac. Bluetooth to the mug, that's the whole data path. I made one small tweak after reviewing it. That was my contribution.
The thing that keeps getting me is how obvious this should have been.
I've got friends who own Ember Mugs. People who have complained to me about the phone-app situation. This is not an obscure problem. It's not a niche use case. It's the most natural thing in the world — you're at your desk, your mug is next to you, you'd like to glance at the menu bar and see if your coffee is still hot.
Ember didn't build it. Third-party developers haven't really cracked it cleanly. And I put together something that handles the core workflow — temperature, battery, heating control, notifications — in roughly the time it takes to watch a movie. That's not me being clever. That's the tools.
Here's the thing that's hard to explain to people who haven't tried this.
The gap between "idea" and "thing that exists and runs on your computer" used to be measured in weeks. You needed to spec it, implement it, debug it, compile it, fix what broke in compiling, debug again. Even if you knew what you were doing, small personal tools took real time. Most of them never got built because the ROI wasn't there. The idea wasn't worth the effort.
That math has completely changed.
The gap is now measured in minutes. And it's not that the tools are doing something cheap — Ember Control is a real application. Real Bluetooth stack. Real unit tests. Real macOS notifications. Real compiled binary with an About card and version numbers. It's not a prototype, it's not a demo, it's software I'm actually using, right now, with my actual mug.
This is what I keep trying to get across when people ask me about AI and software. They expect me to talk about code generation, about AI as a better autocomplete for developers. That's not the interesting part. The interesting part is that the threshold for manifesting an idea into a working piece of software has essentially collapsed. The friction is gone. And when friction disappears from a creative process, the volume of what gets created goes way up.
PromptPocket was a hardware project first — I built a Bluetooth macro keypad out of an ESP32 microcontroller in 2024 to solve the same problem in a different context. It took a whole weekend. Ember Control, which is technically more complex, took twenty minutes of background processing while I did something else. Both solve the right problem. One took a weekend. One took a lunch break I wasn't even paying attention to.
We're still early. The thing I keep thinking about is what happens when this kind of speed hits manufacturing. 3D printing is already getting genuinely good. Material science is catching up. AI-driven design is accelerating. The same collapse in friction that just happened to software is going to happen to physical objects.
You'll describe what you want. The design will generate. The printer will run. And whatever you described will exist. That's not far away. In some narrow contexts it's already here. And once it lands fully, the world is going to look very different from the one where ideas mostly stayed ideas because they weren't worth the effort to build.
Ember Control is free. It's in the Glaze store.
Get it: Here
Ember Control is an independent application, not affiliated with or endorsed by Ember Technologies.