Open Wearables - Open infrastructure for wearable-powered health products.

@sourav_sanyal Three-device cross-talk is exactly where the unified model earns its keep. Quickstart is 5 minutes via Docker, would love to hear how it goes once you've plugged it in. One heads-up: CGM coverage is still in progress (Dexcom is on the roadmap, no committed date yet). Which CGM are you working with? If it's a high-demand one, that's useful signal for prioritization.

@sourav_sanyal haha, yeah that's amazing setup. Let us know on Discord, how it worked! :D

@sourav_sanyal CGMs are already on our roadmap, the problem is they mostly don't provide real-time data via API (most have few minutes delay) but we will get there 😎

@himani_sah1 It is early days, and we're upfront about that. The use cases already showing up are the interesting part: clinical teams auditing algorithms, coaches normalizing HRV across devices, AI builders wiring the MCP server into health coaching tools. We'll be watching what gets built.

@himani_sah1 Early days, yeah - but it's already a full engine :D

@syed_shayanur_rahman Thanks. Developer-first was a deliberate call: if the foundation isn't solid and transparent, everything built on top is fragile.

@syed_shayanur_rahman That's an honor to hear that, thanks!

@ragsyme A meditation app adapting to HRV and stress scores is a solid use case for exactly this. If you build it again, the stress index and HRV baseline algorithms are already in there.

@ragsyme But it still can help you in your next projects ;)

@zerotox The Stripe analogy fits the data layer well:) Where we go further is that Stripe stops at the transaction: we also compute what the data means, with open algorithms you can audit and tune. Health intelligence on top of the plumbing, not just the plumbing.

@zerotox Interesting take, thank you for your kind words!

@mwarcholinski Thanks! Open Wearables is rather B2B product but with a little bit of Claude support you should be able to run it locally as everything is dockerized and shouldn't take more than few minutes or use one-click Railway deployment to set up your own instance in cloud. Then you could also use the MCP server to talk your apple health data and get the feedback you need 😄

@mwarcholinski As Piotr said, it's B2B, but you can still use cloud based providers as a private user (by cloud based I mean Apple, Samsung & Google).

@mwarcholinski that's exactly where we're going with the AI layer - you ask a question in plain language, you get a real answer based on your actual data

not there yet for non-technical users out of the box, but it's the direction. watch this space

@raztronaut Razi this means a lot coming from someone who's actually been in the trenches with this data. The Stripe-for-fintech analogy is exactly the framing we kept coming back to - wearables need that layer or every team just keeps reinventing the same auth + schema mess. Would love to swap notes - DM open. 🙌

@raztronaut Haha, so maybe this is time to try with another product, but this time built around Open Wearables? :D

@jakub_mitka  I’m looking at it in a similar way, something to evaluate on the next relevant project 👍

Nice to see someone from Krakow thinking about it in a client context too. It feels like this could genuinely simplify working with health data, if it delivers on the promise. I’ve also come across the Momentum team before - good to hear they already have a solid track record in

@jakub_mitka Jakub - appreciate the vouch. Product studios with multiple health clients are honestly the cleanest fit for this - one shared layer beats rebuilding integrations for every project.

@jakub_mitka Love to see this added to the studio toolkit! Having a unified API ready to roll out for future health clients is a massive time-saver for agencies. Greetings to Krakow! 👋 And I completely agree-the Momentum team has definitely earned their strong reputation in the healthtech space.

@dominik_cywinski Garmin and Oura don't just get different readings, they measure at different points during sleep and use different averaging methods. When you can't see the formula, you can't even tell if you're comparing the same thing.

@dominik_cywinski Garmin, Oura, Whoop, Apple... every single provider has it's own algorithms. That might be frustrating.

@dominik_cywinski being transparent about how the scores are calculated is one thing, but also having an option to actually tweak these for your is actually pretty awesome, you should give it a try

@dominik_cywinski exactly - same metric, different number, no explanation. you can't make decisions on data you can't trust

and the problem compounds when you switch devices. two years of Oura data vs six months of Garmin and you have no idea if the trend is real or just a formula change

open formulas fix that

@nuseir_yassin1 Two layers to this: normalization handles schema and unit differences so all data speaks the same format before scoring. Sensor accuracy at the hardware level is harder: an optical wrist sensor and a chest strap will read differently, and no software layer fully closes that gap. What we can do is run the same scoring logic on top and let teams tune thresholds for known device biases in their user base.

We cover this topic much more on The Science Behind Wearables: https://thesciencebehindwearables.substack.com/

@nuseir_yassin1 You can set up priorities for providers and devices also.