Building a Data Layer That Can Survive Product Change
Where we started
The first version of TIR Labs looked, from the outside, like a practitioner dashboard for reviewing glucose data.
That was the practical starting point. A practitioner needed a way to look at a patient's glucose patterns, understand what had been happening between visits, and move beyond scattered device screenshots and disconnected exports. So the early product surface centered on CGM review: trends, daily patterns, ambulatory glucose profile, time-in-range, and patient-level context.
But building that first screen made one thing clear quickly: the screen was not the real data model.
A dashboard can be designed around the question it answers today. A data layer has to be designed around the questions the product will need to answer later, including questions that are not visible in the first interface yet.
TIR Labs was never only trying to display glucose points. The product was becoming a practitioner workflow for ongoing care. That meant the system eventually had to understand more than readings: patients and practitioners, enrollment, device connection, patient-generated context, care-team communication, review periods, operational status, and the difference between data that exists and data that is actually useful to a practitioner at a given moment.
The early architecture reflected that tension. We started with mock data behind a thin API boundary so the product and interaction model could move before the database was complete. When Neon Postgres was integrated, CGM analytics became real while other areas stayed intentionally placeholder until they had proper tables and workflows behind them. That was not a shortcut. It was a way of avoiding a worse mistake: pretending the entire product model was already known just because the first dashboard could render.
The first interface gave us a place to start. It could not be allowed to define the whole foundation.
The product kept asking for more
The system had to start representing relationships, not just readings.
Enrollment was the first clear signal. A patient was not just a row in a dashboard. In the practitioner workflow, the same person had to become a client invited by a specific practitioner, with invite state, acceptance state, email delivery, account access, and later a separate device connection. Joining a practitioner's care program and authorizing a phone to share Health Connect data are related events, but they are not the same event. If the data model blurred them, the product would eventually confuse onboarding, consent, and device setup in ways that would be difficult to untangle later.
Health Connect exposed a different version of the same issue. The early glucose work was shaped around Dexcom, because that was where the first sandbox pipeline came from. But the product direction was broader. Android Health Connect, future Apple HealthKit, and direct CGM APIs could all produce glucose-related records with different metadata, source behavior, and operational constraints. That pushed the architecture toward a model that preserved where data came from without making the practitioner experience permanently vendor-shaped.
Activity added another kind of pressure. Steps and workouts have different units, rhythms, and meanings. The product moved away from an all-signals overlay because showing everything at once made the chart less interpretable. That was a product decision, but it depended on a data model that kept signals distinct enough to compare intentionally.
Coverage introduced a different category entirely. Eligibility checks, payer routing, benefit snapshots, and service coverage review do not look like health signals. But they belong to the same practitioner workflow. They answer operational questions that affect whether care can move forward smoothly.
Saved monitors pushed the system again. A saved monitor is not a pinned answer or a frozen card. It is a practitioner-specific, patient-specific definition that should be reevaluated against the current review window. That required the system to represent practitioner intent in a durable, structured way, not as a stale snapshot of a past result.
Architecture followed product pressure, not abstract completeness
The architecture did not evolve from a complete map of the future product.
That is worth saying plainly, because it is easy to make early-stage product work sound cleaner in retrospect. TIR Labs did not begin with a finished data model for every workflow it would eventually support. The product started with a useful surface and kept exposing the next missing distinction.
That pattern shaped how we approached each step. When the CGM dashboard needed real persistence, the job was not to model all possible health data. It was to move the working experience behind a real database without breaking what already existed. When Health Connect entered the picture, the system had to stop being shaped around one source. When enrollment became real, the architecture had to separate practitioner-client relationship from device authorization. When Coverage entered the portal, the workspace had to make room for operational data that did not fit the health-signal model.
Each step forced a more precise question. Not "What data might we ever want?" but "What distinction is the product asking us to preserve now?"
That question kept the work honest. It avoided over-designing before the product had taught us what actually mattered, and it avoided treating every new workflow as a local patch until the system quietly fragmented underneath. Source-agnostic could not mean source-blind. Flexibility could not mean vagueness.
Where this is going
Data architecture is not separate from product judgment.
For TIR Labs, the important question has not been only how to store patient data. It has been how to keep patient data meaningful as the product grows. A glucose reading, an enrollment state, an eligibility response, and a saved monitor do not belong to the same category just because they can all be stored. They become useful only when the system preserves the distinctions that matter to the practitioner workflow.
The data layer is not just the backend underneath the product. It is one of the places where the product decides what it believes about care management: what counts as context, what should remain separate, and what should not be shown as more certain than it really is.
The model will keep changing. But the direction is clearer than it was at the start.