Context that survives the conversation.
A lightweight Type 1 diabetes journal that turns everyday conversation into structured history.
Why I built it
A young family member was diagnosed with Type 1 diabetes.
Her parents were already using a long-running ChatGPT conversation during the day, not as a replacement for medical care, but as a way to make sense of routine situations and keep track of what had happened.
The problem was continuity… as the conversation grew, important context started getting buried or repeated:
- which sensor she used;
- her age and profile;
- recent glucose readings;
- what had happened earlier that day;
- what had happened the day before.
They asked me if there was a better way to keep that context from disappearing, and Tide started from that question!
Keep the conversation. Fix the memory.
I didn’t want to change the interaction they were already comfortable with, so the main interface is still a chat. Tide just gives that conversation a better memory. Today, it can extract and store:
- glucose readings;
- insulin events;
- meals and carbohydrate intake.
That structured history stays available to the rest of the product and can be brought back into future conversations. The user says something once, they do not need to maintain a separate log afterwards.
Context needs time, not just facts
Remembering profile information is useful, but remembering what happened recently, when it happened, and in what order is often more useful.
Tide combines:
- persistent profile context;
- recent structured events;
- glucose history;
- the latest known state.
That means the conversation does not have to depend on an increasingly long transcript to reconstruct what happened yesterday.
From chat to structured history
A message does not have to remain just a message! If someone mentions a glucose reading, an insulin event or a meal, Tide can turn it into a structured entry. That information then becomes available in:
- the monitor;
- the history timeline;
- future chat context.
The information is captured once, in natural language, and then reused without asking the user to keep several systems in sync.
A deliberately small monitor
The monitor is intentionally small. It shows:
- current and recent glucose state;
- recent glucose history;
- the active profile and protocol context.
I deliberately did not turn it into a medical dashboard full of charts and metrics. The goal was to make recent context easier to see, not to create another system the family had to maintain.
Search with boundaries
External web search is off by default, but if the user enables it, Tide only searches a small whitelist of trusted diabetes and health sources that can even be updated in the settings!
Local first. Shared only when needed.
Like Contas, Tide is local-first, so data stays on the device.
However, for the small private family setting it was built for, I also added optional synchronization through Firestore. A random secret code identifies the shared workspace and lets the same data be accessed across devices.
I deliberately kept this lightweight instead of building a full account system for a tool used by a handful of family members.
What Tide is, and what it is not
Tide is a private family tool for context, journaling and continuity around everyday Type 1 diabetes routines. It is not a diagnostic system, not a clinical product, and not a replacement for medical professionals.
That boundary shaped the product from the start: the goal was to preserve useful context and history, not to make the model pretend it should make medical decisions.
Where it is now
Tide is live and usable, still being used in the family setting it was built for, and you can try it yourself!
What I learned
Context is more than memory
Remembering facts is useful, but remembering sequence and recency is often more useful. In a long-running conversation, knowing what happened yesterday can matter more than storing another static profile field.
Structure can emerge from conversation
If the information is already being expressed naturally, people should not have to enter it again somewhere else. Turning conversation into structured history made the product more useful without asking the user to change their behaviour.
In sensitive domains, restraint is a feature
More capability is not always better. Opt-in search, narrower sources and a deliberately small product surface were more useful here than trying to make the system do everything.