GastroGuard
GI symptom, meal, and context logging with per-user trigger analysis.
Active developmentTested with 10 users over ~1 month- Division
- HeartWire
- Role
- Founder · design and development
- Timeline
- 2025 – present
Structured capture of symptoms, meals, stress, and sleep, analysed per person. The aim is to replace a paper diary that nobody analyses with a record that surfaces candidate triggers for the user to discuss with a clinician.
- Next.js
- TypeScript
- Supabase (Auth · Postgres · RLS)
- PWA
- Vercel
01Problem / user need
Functional and inflammatory GI conditions flare in response to triggers that are multifactorial and individual: diet, stress, sleep, and timing interact differently per person. The standard tools — a paper food-and-symptom diary or a structured elimination protocol — generate observations faster than anyone analyses them, and depend on recall.
The gap isn’t capture. It’s structured capture plus per-individual analysis, so the record can be interpreted without waiting for a ten-minute visual scan at a clinic visit.
02Requirements
| # | Requirement | Acceptance criterion | Status |
|---|---|---|---|
| R1 | Logging friction | Symptom + meal entry completes within a bounded median time | Derivable from existing timestamps; not yet computed |
| R2 | Adherence | Share of users logging on most days of a 7-day window | Computable from the existing cohort; not yet computed |
| R3 | Auth isolation | User A cannot read or mutate user B’s rows | Not yet tested |
| R4 | Model performance | Beats a per-user base-rate baseline on held-out data | Not published — evaluation split must be confirmed first |
| R5 | Explainability | Every surfaced trigger traces to the rule or statistic that produced it | Design goal |
| R6 | Cohort | ≥ 10 users over ≥ 1 month | Met — 10 users, ~1 month |
03Architecture
┌──────────────────────────────────────────────────┐
│ CLIENT — Next.js PWA (TypeScript) │
│ symptom log · meal log · stress / sleep entry │
│ insight views │
└────────────────────────┬─────────────────────────┘
│ HTTPS
┌────────────────────────▼─────────────────────────┐
│ SUPABASE │
│ ├─ Auth + RLS (per-user isolation) │
│ └─ Postgres: symptom · meal · context tables │
└────────────────────────┬─────────────────────────┘
│
┌────────────────────────▼─────────────────────────┐
│ ANALYSIS LAYER │
│ deterministic rule set │
│ + correlation / predictive model │
│ → ranked candidate triggers │
└──────────────────────────────────────────────────┘
╭┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄╮
┊ external health-platform API (HRV, sleep) ┊ NOT CONNECTED
┊ vendor-neutral ingestion interface ┊
╰┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄┄╯04Design decisions
Hybrid rules + statistical model instead of pure ML
- Chosen
- A deterministic rule set combined with a correlation/predictive model.
- Alternative
- An end-to-end learned model over every logged variable.
- Tradeoff
- Ten users over a month is nowhere near enough data for a learned model to generalise; it would fit noise and report it as insight. Rules give output on a new user’s first day, are auditable, and let every surfaced trigger be traced. Cost: rules only find relationships I thought to encode — the model half exists to catch what they miss.
Server-first PWA instead of local-first native
- Chosen
- Next.js + Supabase, one codebase, deployed on Vercel.
- Tradeoff
- Fast iteration, cross-device sync, and no app-store review. Cost: sensitive health data leaves the device, so privacy rests on RLS correctness; and the richest wearable sources are native-only.
Vendor-neutral ingestion interface for wearable data
- Chosen
- Design against any health platform that exposes a public API, rather than one vendor’s SDK.
- Tradeoff
- Not locked to one vendor. Cost: it is also why the path doesn’t run yet — public web APIs generally don’t expose raw HRV to a browser client, which is a direct consequence of the server-first PWA decision above.
4.5Scope & role
Independent project under Terrero Labs. I built the app, schema, and analysis layer and ran the 10-user test period.
05Implementation
- Software: Next.js PWA in TypeScript; Supabase Auth, Postgres, and RLS; deployed on Vercel.
- Analysis: deterministic rules combined with a correlation/predictive component that ranks candidate triggers per user.
- Wearable ingestion (HRV, sleep): an interface was designed; no live source is connected and no wearable data has been ingested.
- Hardware: none.
06Verification
The app was used by 10 people over roughly one month, and an evaluation set exists.
PendingNo model performance number is published. Before one is, I need to confirm the evaluation split is by user (leave-one-subject-out) or forward in time — a pooled random split lets the model recognise individual users and inflates results — and state how multiple comparisons across candidate triggers are corrected. Adherence statistics from the existing cohort come first: they need no new data.
07Failures / iterations
- Wearable ingestion was designed and never connected. The cause is the coupling between two of my own decisions: a browser-first app and data sources that are native-only.
- I scoped the analysis away from a learned-only model once the sample size made it clear a model would fit noise.
08Limitations
- Not a medical device. Makes no diagnostic, therapeutic, or dietary-treatment claim and has not been evaluated under any FDA pathway. Output is framed as candidate associations to discuss with a clinician — never as “this food causes your condition”.
- Cohort: 10 users over about a month. Exploratory and not generalisable; no external validation cohort.
- All inputs are self-reported and subject to recall and adherence bias. No physiological ground truth.
- Observations within a user aren’t independent; any analysis that treats them as independent overstates confidence.
- Associations are correlational. Reverse causation is plausible in this domain — a flare-up changes what a person eats.
- No clinical review of the rule set and no external security audit.
09Repository / demo / report
- Live appgastro-guard-bice.vercel.app/
- Repositorygithub.com/jonnyterrero/gastro-guard