# RingConn and the Case for Dumb Hardware I bought a RingConn. Not an Oura. The choice was deliberate. --- ## The Oura Problem Oura is a good product. It's also an opinionated one. Every data point arrives pre-interpreted: 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 don't want to stare at HRV charts and decide for themselves whether 45ms is good or bad. They want a number that says "you're at 78% today, maybe take it easy." But that interpretation layer is also a ceiling. You can't ask questions the app didn't anticipate. You can't weight variables differently based on your own context. You can't integrate the data with other systems in ways Oura didn't build for. The narrative is fixed. You're just reading it. --- ## The RingConn Bet RingConn is less polished. The app is functional, not delightful. The insights are basic. The UI doesn't tell a story the way Oura does. That's the feature. What 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: if the device won't narrativize for me, I can narrativize for myself. Better yet, I can build an MCP server that: 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** (not generic "readiness" but "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's 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's 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's what most users want. But interpretation is also lock-in. The insights are only as good as the product team's imagination, and they're not tuned to your specific context. Raw data + MCP + LLM = bespoke interpretation. RingConn isn't the better ring. It's 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