Tide

The realtime recovery layer for the Hydrawav3 belt

Comment

Tide - Hydrawav3 Recovery Intelligence Track

The prompt asks for intelligence layered on top of the Hydrawav3 belt: software that turns a vibration device into a practice-grade recovery tool. Tide answers it directly. Every screen, from the QR on the practitioner desk to the shareable summary card on the client's phone, exists to make a Hydrawav3 session smarter, more connected, and more memorable.

Live demo: hydrawav3.vercel.app

Inspiration

Recovery practitioners using the Hydrawav3 belt are stuck between two bad categories of software. Session timers are dumb: they run a clock, maybe a preset, and leave the conversation, the body assessment, and the handoff to the client to sticky notes and memory. EMRs are bloated: they were built for insurance billing, not for a forty-five-minute hands-on session where the practitioner and client are looking at the same body together. Neither category captures the moment that matters. The conversation gets lost. The intake never makes it into the recommendation. The client leaves with nothing to hold onto, and the practice has no structured signal to tell who needs a follow-up.

We kept coming back to one image that answers all of it: a practitioner and a client looking at the same glowing 3D body from opposite sides of the room, one on a tablet and one on a phone, the zones lighting up in sync as the session unfolds. That image is the whole product. The Hydrawav3 belt is a serious piece of hardware. The software layer around it should be just as serious. Tide is the missing layer that makes it real.

What it does

Tide is a realtime recovery layer for the Hydrawav3 belt. One Next.js app, two synchronized surfaces, a streaming AI pipeline, and a pair of deterministic rule engines for clinical judgment.

  • Check-in is a handshake. The practitioner's tablet rotates a signed HMAC token into a QR every four minutes. The client scans it on their phone and both surfaces snap to the session view on the same tick.
  • Recommendation is deterministic. A rule engine runs against the client's health snapshots and prior notes, producing four independent, traceable reasoning lines (HRV drop, resting-HR delta, low-sleep run, asymmetry keywords).
  • Intake is streamed through AI. Audio flows through ElevenLabs Scribe for diarization, then Gemini 3 Flash for structured extraction. Each note becomes a typed row with note_type, quote, rationale, flagged, and affectedZones.
  • The body is the shared state. A single body-zone state machine drives two three.js scenes over Insforge realtime. When Gemini tags a note with ["lumbar", "right_glute"], both bodies glow in the same places in the same animation frame.
  • The session is recorded with consent. A two-party consent pill sits in the live header the whole time Scribe is running. It is not hideable and not gated behind a setting.
  • The summary meets the client where they are. A site-wide listener pops the summary sheet on whatever screen the phone is on, home, history, coherence, or settings.
  • Relapse intelligence is rule-based. Three signals (HRV trending down for 7+ days, 2+ flagged complaints, 14+ days since last visit) collapse into low, medium, or high severity flags. The practitioner can draft an outreach in one tap.
  • Privacy propagates live. Toggling a stream off on the phone hides that client from the practitioner's relapse list on the next tick.

The whole product earns its existence in one beat you can watch on video: the practitioner says the word "lumbar" out loud, a note chip animates onto their tablet, and on the client's phone the lower back of the 3D body lights up in the same animation frame. Two physical devices, one glowing body, zero delay. That is the moment the software disappears and the session becomes the product.

How we built it

Architecture

                    ┌──────────────────────────────┐
                    │   Insforge  (Postgres + rt)  │
                    │   practitioners  clients     │
                    │   sessions       notes       │
                    │   snapshots      flags       │
                    └──────────────┬───────────────┘
                                   │   pub / sub
            ┌──────────────────────┴──────────────────────┐
            ▼                                             ▼
  ┌────────────────────┐                        ┌─────────────────────┐
  │  Client  (mobile)  │                        │ Practitioner (desk) │
  │  /client/*         │◀─ signed QR (HMAC) ─▶│ /practitioner/*     │
  └────────────────────┘                        └─────────────────────┘

One Postgres plus realtime backend, one shared body-zone state machine, two three.js scenes, two form-factor-aware route trees, one auth cookie gating both. middleware.ts sends mobile user agents into /client/* and everything else into /practitioner/*.

The AI pipeline

Every audio segment flows through a two-stage pipeline:

  1. ElevenLabs Scribe does speaker diarization and timing.
  2. Gemini 3 Flash runs structured extraction with a rigid JSON schema, producing typed rows we can render without ever piping free-form text to the interface.

Each extracted row writes to session_notes and publishes on both session:{id}:notes and body:{clientId}. The body-zone state machine on each side consumes zones_updated and repaints the three.js scene. Two scenes, one source of truth, zero polling.

The deterministic layer

Two rule engines hold the clinical loop:

  • lib/protocol-rules.ts computes the recommendation card from real Postgres rows. HRV trend, resting HR delta, sleep run, asymmetry keywords. Every line on the card is traceable to a specific row.
  • lib/relapse-rules.ts collapses three signals into severity:

$$ \text{severity} = f\big(\Delta_{\text{HRV, 7d}},\ n_{\text{flags}},\ \Delta t_{\text{visit}}\big) $$

No model in either engine. The AI colors the session. It does not issue the verdicts.

The handshake

Pairing is the interesting bit. Every four minutes the tablet rotates a fresh HMAC-signed token:

$$ \text{token} = \text{HMAC}_{k}\big(\text{practitionerId}\ |\ \text{issuedAt}\ |\ \text{ttl}\big) $$

The phone scans, posts { token, clientId } to /api/checkin, and the server validates, inserts a session row, and publishes on checkin:{practitionerId}. Both surfaces react on the same tick. No shared local storage. No copy-paste codes. No second handshake.

Device control

lib/mqtt.ts authenticates against the real Hydrawav3 MQTT-over-HTTP bridge for a JWT and publishes the full session config (playCmd, cycleRepetitions, leftFuncs, rightFuncs, pwmValues, hotDrop, coldDrop, vibMin, vibMax, totalDuration) on HydraWav3Pro/config. The belt runs for real.

Stack

Next.js 15 App Router, React 18, TypeScript 5. Insforge for Postgres and realtime. ElevenLabs Scribe. Gemini 3 Flash. three.js with a GLTF human figure. MediaPipe Tasks-Vision for squat depth and shoulder flexion capture. qrcode.react on the tablet, @yudiel/react-qr-scanner on the phone. Framer Motion, Zustand with persist, html2canvas, next/og. Hosted on Vercel.

Challenges we ran into

  • Cross-device realtime is a different shape of problem than single-device state. Our first instinct was Zustand with localStorage for everything. That works on one laptop and collapses the moment two physical devices come into the room. We rebuilt the live paths around Insforge channels and kept Zustand only as a single-device convenience.
  • Structured output is a clinical contract, not a convenience. Early versions of the intake pipeline piped Gemini's free-form text into the UI. It looked fine in a demo and would have been a disaster in a real clinic. We rewrote the Gemini call to produce a rigid schema so every transcript chip, body zone, and note card reads from the same typed row.
  • Two three.js scenes, one body. Keeping both bodies painting the same zones in the same animation frame without tearing or drift took a dedicated body-zone state machine. The naive approach (each scene owns its own state, updated by the same event) produced visible skew on slow networks.
  • The phone is not always on the session screen. The summary card needs to arrive wherever the client happens to be: home, history, coherence, settings. We solved it with a site-wide listener mounted in the client root layout that pops a full-screen sheet on the summary:{clientId} channel.
  • The demo has to be clean every rehearsal. /client/login wipes tide-session, tide-body-state, and tide-pose on mount so Alina is always a first-time client. Without that, the tenth rehearsal of the day showed stale state and broke the illusion.
  • Real device control under a stage audio loop. The Hydrawav3 MQTT bridge expects a real JWT and a real MAC. We kept the auth flow real and added a sample-MAC fallback for when the paired belt is unreachable, so the belt still fires during the demo.

What we learned

  • Rule engines beat models in the clinical loop. The temptation to let Gemini issue recommendations directly was real. Putting a deterministic layer between the AI and the clinical interface made the product dramatically more trustworthy without making it less magical. The AI colors the session. It does not issue the verdicts.
  • Structured output is how AI becomes a UI primitive. Constraining the model to a schema turned a "what does the AI say" feature into a set of typed rows we can render, animate, and reason about.
  • Realtime fanout is cheaper than re-fetching. Every interesting state change travels through a single Insforge channel. No polling, no cache busting, no reconciliation.
  • Form-factor routing at the edge is a feature, not a trick. A single middleware.ts that sends mobile to /client/* and desktop to /practitioner/* with one shared auth cookie let us ship two surfaces as one app without a second auth stack or a second deployment.
  • Visual polish is not optional. In a recovery product, the difference between medical software and something you would actually want to use is a motion pass and a typography pass. We budgeted time for both.
  • The best way to extend a hardware company is to attach software to its installed base. The Hydrawav3 belt is already in the room. Tide does not ask the clinic to adopt a new stack, a new login, or a new vendor. It rides the relationship that already exists.

Business model and go-to-market

Tide sells as a premium B2B tier inside Hydrawav3's existing practitioner relationship. Same buyer as the belt, same billing account, higher ARPU. Solo practitioners pay $129 per seat per month (one belt, one practitioner, 100 active clients). Recovery studios and small PT or chiro practices pay $99 per seat per month for the Clinic tier (2 to 10 seats, up to 5 belts, scheduling, multi-bay routing, revenue and retention dashboard, two-party consent audit log). Franchise chains, pro sports teams, and corporate wellness buy Enterprise from $1,499 per month (SSO, HIPAA BAA, EMR export, white-label, custom protocol library, REST API). The math is honest: the belt is a one-time $2,500, Tide Solo is $1,548 per year, and a single recovered rebook per month at $150 covers the subscription. A five-seat Clinic pays back on two rebooks per month across the team.

The first 1,000 customers come from the installed base, not from cold outbound. Every new professional belt order ships with a 60-day Tide trial. Month 3 invoices auto-enroll at the matching tier, and billing flows through the existing Hydrawav3 account so there is no new stack to stand up. The primary buyer is the clinic owner-operator who owns the belt and runs the sessions. The second is the multi-seat clinic manager. Enterprise buyers come last and come warmer, because the attached clinics are already their reference customers. Once Tide is entrenched inside Hydrawav3 clinics, the intake pipeline, body-zone state machine, and summary-card layer are modality-agnostic enough to serve adjacent recovery modalities (PT, chiro, sports performance), extending Hydrawav3's reach without new hardware.

From here the natural next steps are native Android Health Connect and Apple HealthKit bridges (replacing the signed ingestion endpoint used during the demo), platform push notifications alongside the in-app realtime sheet, a practitioner-authored protocol library so clinics can codify their own house recipes, and an Enterprise EMR export path for teams that need Tide sessions to land in their existing record system.

Built With

  • 3d-model
  • elevenlabs
  • gemini
  • insforge
  • next.js
  • vercel
Share this project:

Updates