# RingConn and the Case for Dumb Hardware I bought a RingConn over an Oura, and the choice was deliberate. ## The Oura Problem Oura is a good product. It is also an opinionated one. Every data point arrives pre-interpreted as your "Readiness Score," your "Sleep Quality," your "Activity Goal." The ring collects raw biometrics but the app decides what they mean before you ever see them. This is the right design for most users. Most people do not want to stare at HRV charts and decide for themselves whether 45ms is good or bad. They want a number that says "you are at 78% today, maybe take it easy." But that interpretation layer is also a ceiling. You cannot ask questions the app did not anticipate. You cannot weight variables differently based on your own context. You cannot integrate the data with other systems in ways Oura did not build for. The narrative is fixed. You are just reading it. ## The RingConn Bet RingConn is less polished. The app is functional. The insights are basic. The UI does not tell a story the way Oura does. That is the feature. RingConn does offer raw data export, API access, and a less aggressive interpretation layer. The hardware collects. The software displays. The gap between collection and meaning is left open. That gap is where I want to build. ## MCP as the Interpretation Layer The thesis is that if the device will not narrativize for me, I can narrativize for myself. Better yet, I can build an MCP server with three jobs. 1. **Pulls raw RingConn data** (sleep stages, HRV, SpO2, temperature, activity) 2. **Correlates with external context** (calendar density, travel, alcohol, training load) 3. **Generates insights tuned to my questions** (questions like "should I do the hard workout or the recovery session today given last night's data and this week's stress load") The LLM becomes the interpretation layer. Claude can synthesize across data sources that would never talk to each other in a closed ecosystem. The MCP architecture makes the data available. The prompt shapes the narrative. ## Why This Matters Beyond Fitness Tracking This is a micro-case of a larger pattern. The best hardware for AI integration might be the hardware that does less. | Product Philosophy | AI Opportunity | |-------------------|----------------| | Opinionated UI, rich insights | Low. The product already decided what the data means. | | Minimal UI, raw data access | High. The interpretation layer is unbundled and available. | Oura is a finished product. RingConn is a sensor with an app attached. For most users, Oura wins. For someone who wants to build their own intelligence layer on top, the "worse" product is actually better. ## The Experiment **Phase 1:** Get RingConn data flowing into a local MCP server. Explore what is available via their API or export. **Phase 2:** Build correlation hooks. Calendar (busyness), weather (seasonal patterns), manual inputs (alcohol, stress events). **Phase 3:** Prompt engineering. What questions do I actually want answered? "How did I sleep" is boring. "Given my sleep and HRV trend this week, what is my realistic capacity for deep work today?" is useful. **Phase 4:** Surface the insights. Maybe a morning briefing. Maybe integration with daily notes. Maybe just a Claude conversation that has context. ## The Larger Point The wearable market optimized for interpretation because that is what most users want. But interpretation is also lock-in. The insights are only as good as the product team's imagination, and they are not tuned to your specific context. Raw data + MCP + LLM = bespoke interpretation. RingConn is the better substrate for building what I actually want. --- **See also:** - [[01.24.26 - Personal Reliability Engineering - Synthetics, Playwright, Automated Testing]] - Related thinking on self-monitoring infrastructure - [[Thesis - Current tools are lossy membranes]] - The broader pattern of interpretation layers as constraints