An ER visit can turn a simple question into a memory test

When did it start? What happened before it? What did you take? Has this happened before? What changed since the last episode?

You may have waited months to see a specialist, but now you are expected to reconstruct everything while you are in pain, stressed, tired, or mentally foggy. Important details get missed. Some details get remembered incorrectly. The whole appointment starts depending on a story that is being reconstructed under pressure.

That problem is why I started building PriorTo. PriorTo is a local-first symptom record for recurring, episodic conditions. It is designed to be used during an episode, not several days later when the person is feeling better.

The first version is deliberately narrow:

• Start an episode with one tap.
• Log repeat observations without typing.
• Close the episode when it ends.
• Review the timeline before an appointment.
• Export a concise clinician handoff when needed.

The most important part is not the timeline itself. It is the distinction between what was recorded in the moment and what was added later from memory.

Memory should not look like evidence

PriorTo derives provenance from two timestamps:

1. When the event happened.

2. When the person recorded it.

If an entry is added later, PriorTo does not quietly merge it with the live record. It shows that the entry was recalled and displays the actual gap. No button lets someone label a memory as “confirmed.” The record makes the distinction from its own timestamps.

That decision affects the entire system. Corrections are appended instead of silently rewriting history. If a stored line cannot be read, the account reports that the record is incomplete instead of pretending nothing happened.

Why PriorTo is local-first

Health records are sensitive, and PriorTo does not need a cloud account to do its core job.

The episode data stays in local app files. The storage model uses a small header plus an append-only per-episode log. Each observation is written as a separate record, so a crash does not require rewriting the entire episode.

The app uses a strictly parsed domain model for conditions, episodes, observations, and log entries. The current account is reconstructed by folding the log.

The export is also rendered on the device and handed to the operating system share sheet. PriorTo does not send symptom labels, notes, severity values, timestamps, or PDF contents to a server.

The app performs no diagnosis, triage, severity classification, treatment advice, prediction, or trigger detection. No language model writes any part of the record. It records what the person entered and organizes it in time.

The paid boundary

The core record remains free. Logging, reading, correcting, deleting, and reviewing episodes do not require a purchase.

The first five clinician handoffs are free. After that, the export can be unlocked through annual access or clinician-sponsored access.

This boundary matters because nothing needed while someone is unwell should sit behind a paywall. The paid feature is the convenience of turning the record into a document designed for another person to read. The user can always view their own record on the device for free.

RevenueCat is being used only at the purchase and entitlement boundary. It does not receive health data.

What's built so far

PriorTo is an Android-first Expo and React Native project written in TypeScript.

The current implementation includes:

• Append-only episode storage.
• Strict parsing and failure-closed schema handling.
• Live versus recalled provenance.
• Incomplete-record reporting.
• One-tap capture for repeat observations.
• Episode history.
• Offline clinician document rendering.
• RevenueCat Test Store product and entitlement wiring.

The repository currently passes its automated checks with 111 tests, and the Android export bundle completes successfully.

The remaining gates are the ones that cannot be honestly simulated on a desktop: a native development build, a real purchase and restore flow, and physical-device testing while the app is being used under stress.

What I am trying to learn

I am building PriorTo in public during Shipaton 2026 because the product needs feedback from people who have actually seen this problem.

• For clinicians: what information is genuinely useful in a first handoff from a patient with a recurring condition?
• For patients: what would make you record an episode in the moment without turning the app into another daily habit tracker?

PriorTo is not trying to interpret a person’s health. It is trying to help them preserve what happened before they are asked to explain it.