MyPepProtocol
Designing a health record around evidence, not assumptions.
MyPepProtocol is a private health product for people managing complex protocols and the records that accumulate around them.
I started with a practical problem: the same information was being repeated across setup, schedules, inventory, labs and notes, while the context connecting those records was easy to lose.
The product is built around a simple idea: record facts once, reuse them carefully, and keep the evidence behind any summary close enough to inspect.
Independent product · Live in early access · Ongoing development
Product rules
Four constraints that shape the product.
Record once.
If the product already has a fact, it should not ask for it again without a reason.
Do not turn missing information into an assumption.
Convenience should reduce unnecessary input, not make decisions for the user.
Keep intent separate from history.
Something planned for the future should not appear as something that already happened.
Make uncertainty visible.
When the record cannot support a comparison or conclusion, the interface should say so.
Decision 01
MyPepProtocol / Setup journey
From inventory to a protocol.
User problem
People could record an inventory item, but starting a protocol meant entering the same details again.
Product decision
Reuse known details.
Keep the user in control.
Prefill only recorded name, strength, unit and compatible preparation details. Let the user review the values and choose when to start. Do not infer dose, schedule or inventory quantity.
The distinction matters. Inventory can tell the product what someone owns. It cannot tell the product how, when, or whether that item should be used.
Decision 02
MyPepProtocol / Lifecycle
Planned is not the same as active.
User problem
Someone may know what they intend to use without knowing when they will begin. Treating that plan as active would immediately give it a week number, schedule and place in the health timeline.
Product decision
Preserve the setup.
Do not create history before it exists.
A Planned protocol can keep its compounds and dosing setup without a start date. It stays separate from active protocols, today's schedule and recorded treatment history.
When the user is ready, activation asks for a start date and keeps the setup they already entered.
That required treating “planned” as a real product state, not just another label on an active record.
Decision 03
MyPepProtocol / Health history
Show the change. Keep the caveat.
User problem
A health record can contain dozens of measurements across different dates, units and sources. Showing every delta creates noise. Comparing everything automatically creates false confidence.
Product decision
Rank what is useful.
Leave unsupported comparisons unresolved.
MyPepProtocol derives changes from recorded evidence before deciding what deserves attention in the interface.
Compatible history can show movement over time and a descriptive personal baseline. Incompatible units stay separate. Ambiguous same-day results are not averaged into a cleaner answer. Imported results with low extraction confidence keep a visible verification warning.
The interface then surfaces only a small number of useful findings by default, with the underlying evidence and limitations available when someone wants to inspect them.
The ranking is presentation priority, not medical urgency.
Decision 04
MyPepProtocol / Guided analysis
Put AI after the evidence.
User problem
AI can make a complicated record easier to scan. It can also invent context, overstate a relationship, or turn timing into causality if the boundaries are vague.
Product decision
Establish the facts first.
Let AI explain within them.
The Guided Health Analyst begins with focused questions such as what changed since the last labs, what information is missing, or what protocol timing was recorded around a lab date.
The product assembles the relevant evidence first. AI processing requires the user's consent, and each generated finding has to point back to evidence the system actually supplied.
The interface keeps that evidence inspectable and shows evidence limits alongside the summary.
The same principle carries into Doctor Report: the report facts are deterministic. AI can optionally help phrase a short overview, but the report does not depend on it.
Constraints
Deliberate constraints
Some of the most important product decisions were decisions not to automate.
Inventory quantity does not decrease simply because a protocol was created. Planned treatments do not become active history until a start date exists. Mixed or ambiguous lab evidence is not silently normalized into a comparison. Timing between a protocol change and a lab result is not presented as proof that one caused the other.
These choices leave some manual work and some unanswered questions. That is preferable to making the record look more certain than the underlying evidence supports.
Lessons
What the project changed in how I build
Reducing input and reducing user control are different things.
Good defaults should remove repetition while leaving consequential decisions visible.
Uncertainty needs its own product design.
“We do not have enough evidence to say” is a useful state, not an error to hide.
AI became more useful after the non-AI product rules were explicit.
The stronger the evidence model and constraints became, the narrower and more useful the AI's job became.
Status
Current status
MyPepProtocol is live in early access and remains under active development.
The current direction is consistent with the decisions above: reduce unnecessary maintenance, keep longitudinal records connected, surface useful context quickly, and preserve the evidence and limitations behind it.
Current product
See the current product
MyPepProtocol is a working product, not a static prototype.