Pet Med Reminder: let a course end

Small batch. One session.

Problem

A vet does not prescribe “daily.” A vet prescribes “0.5 mL orally once daily for 3 days.”

Here is a real discharge email for two foster kittens, forwarded to me by the person caring for them after she declined to try the app. Names removed, doses as written:

Kitten A                              Kitten B
Panacur     0.5 mL daily, 3 days      Panacur     0.3 mL daily, 3 days
Ponazuril   0.5 mL daily, 3 days      Ponazuril   0.3 mL daily, 3 days
Itrafungol  0.5 mL daily, 14 days     Itrafungol  0.3 mL daily, 14 days
Miconazole  thin layer to the patch   Lime sulfur, instructions at pickup
Lime sulfur, instructions at pickup

Nine items. Every line carries a duration. The app cannot represent one of them.

An end date is already on the data model. The code that generates doses already stops past it. The code that computes the next dose already returns nothing past it. The engine has understood finite courses since May. The editor has no field for it and never sets it, so on a newly created item it is empty forever. The capability exists and nothing on screen can reach it.

What she would get instead is a daily reminder that runs until she remembers to go and delete it on day four. That is worse than a screenshot of the email, which at least says “for 3 days.” She was right to decline.

Two more consequences of the same missing field:

• A finished course never looks finished. The active flag is set to true when an item is created and is never written again anywhere in the app. The pet screen filters on it, so a course that ended in July still sits in the list looking live.
• Nobody knows where they are. Day nine of a fourteen-day course is exactly where memory fails, and the app cannot say “day 9 of 14” because it does not know there are fourteen.

This is not a fostering feature. Every post-surgery course, every ten-day antibiotic, every ear infection is finite, and the chronic-illness household this app was built for has courses too: the diabetic cat on lifetime insulin also gets a two-week antibiotic.

Appetite

One session.

No schema change, no sync deploy, no notification work. The end date already ships in the deployed schema, and notifications are scheduled from generated dose rows rather than recomputed from the schedule, so they stop on their own the moment the generator stops. This is a form control, a derived label and a list section.

If it starts to feel like a week, something from No-gos has crept in.

Solution

Three moves.

1. An optional “Ends” control in the editor, entered in days. The vet says “for 14 days,” so the input is a day count, not a date picker. It is stored as the end of the last day, so the ceiling clears the final dose whatever time it falls at. The default is no end date, so today’s behaviour is untouched and Save is never blocked. Changing the start date recomputes it. Opening an existing item derives the day count back for display.

2. “Day 9 of 14” wherever a dose or a care item appears. This is the move that makes the field worth more than a delete reminder. Computed from the start and end, never stored. One line of copy is the whole feature, and it answers the question her list cannot.

3. A finished course reads as finished. Add a computed “finished” test and a Finished section below the live items. Do not write the active flag. Deriving costs nothing, and a background write to flip a stored flag is how sync bugs start.

How we know it worked: care items created with an end date, as a share of care items created. If that is near zero after two weeks of installs, the control is in the wrong place and this pitch was wrong about how much it mattered.

Rabbit holes

• Days, not doses. “14 days” and “14 doses” diverge the moment a dose is given late, and this app already re-anchors on late doses. A calendar end date is a hard ceiling, so a late start silently loses the tail. That is the wrong answer for a vet who meant fourteen doses, and it is explicitly not being solved here. Days is what the prescription says and what the engine already enforces. Log the tension, ship the calendar.
• Do not touch the frequency picker. The new control sits below it and does not interact with it. Every frequency mode gets the same day-count ceiling.
• Do not turn the editor into a wizard. An earlier batch cut this exact form down because both funnel bounces rage-clicked on this screen. One optional control, defaulted off, that never blocks Save.
• “Day 9 of 14” is copy, and copy is where sessions disappear. Write one version, ship it.

No-gos

• Multiple times per day, the sibling gap in the same form. Real, and a working if ugly path already exists. Not in this batch.
• Auto-archiving or auto-deleting finished courses. Derived display only. Deleting a course destroys the dose history, which is the one asset this app has that a screenshot does not.
• The Today tab redesign. Same answer as last time.
• Any schema change. If this pitch grows a duration column it has failed. The whole reason it is one session is that the end date already ships.

---

What this cost me to learn: she told me the system she already had worked fine, and because that sounded like a preference I agreed with it and sent my App Store link anyway. It was a defect report with the evidence attached, and I skimmed past the evidence. When somebody says a product is not for them, the thing to ask for is the thing they use instead. The workaround is the specification.