ShotNest · 2026
A connected treatment-management system for iPhone and Apple Watch
Making the next step unmistakable.
ShotNest brings dose timing, injection history, medication supply, side effects, progress, and learning into one coherent routine. I defined, designed, engineered, and prepared the product for release as one connected system.
Role
Founder & AI-Native Product Builder
Product strategy, discovery, architecture, interaction design, implementation, validation, and release planning.
Product scope
Onboarding, reminders, shot and symptom logging, medication supply, progress, learning, HealthKit, and Watch surfaces.
Technical foundation
Expo · React Native · TypeScript
Local-first storage · Apple HealthKit · Apple Watch
Product state
Working release foundation
Core product flows implemented, tested, and prepared for App Store submission.
How might we
Help people self-managing injectable GLP-1 treatment understand what happened, what is next, and whether they are prepared.
So that
treatment routines feel coordinated and trustworthy instead of fragmented across memory, notes, calendars, and disconnected apps.
Problem definition
Fragmentation creates cognitive load at every point in the treatment cycle.
A weekly injection looks simple until the routine breaks. People must remember timing, interpret dose information, rotate injection sites, understand symptoms relative to the last shot, monitor progress, and know whether enough medication remains for the next dose.
Temporal uncertainty
Treatment schedules are easy to lose when travel, illness, or everyday disruption shifts a familiar weekly rhythm.
Disconnected evidence
Dose history, symptoms, weight, and notes often live in separate tools, making it difficult to interpret progress in context.
Supply ambiguity
A package count does not always answer the practical question: how many usable doses remain, and when will the current supply run out?
Clinical complexity
Concentrations, delivery methods, and treatment changes introduce rules that a general-purpose tracker is not designed to represent.
Discovery research
Research clarified the difference between a reminder and a treatment system.
I reviewed 23 directional survey responses from GLP-1 users recruited through Reddit and Facebook communities. I did not treat the responses as a statistically representative clinical sample. I used them to identify repeated behaviors, workarounds, and emotionally significant moments in the routine.
Respondents described combining calendars, spreadsheets, journals, memory, Shotsy, MyFitnessPal, and Apple Health. The opportunity was therefore broader than adding another reminder: the product needed to connect dose timing, progress, side effects, and preparation.
23
survey responses reviewed for directional discovery and problem framing.
15
respondents identified shot schedule and reminders as a reason to use an app regularly.
22
respondents tracked weight, making progress visibility the strongest shared behavior.
Discovery system
01
Frame
Defined the unmet need, target audiences, problem statement, hypothesis, and a shared how-might-we question.
02
Compare
Reviewed adjacent GLP-1 products to separate category conventions from gaps worth solving.
03
Map
Connected activities, user stories, workarounds, emotional highs and lows, pain points, and opportunity areas.
04
Sequence
Converted the opportunity space into a phased roadmap and state-aware information architecture.
Behavioral scope
I mapped the whole routine before designing the first screen.
I broke each activity into user stories across onboarding, injections, side effects, progress, reminders, reports, personalization, and learning. The map exposed dependencies and gave the MVP a defensible boundary instead of a feature wish list.
User story map
A shared view of the complete GLP-1 routine, organized from high-level activities down to implementable stories. Select the artifact to inspect it.
Competitive review
Feature matrices and flow teardowns surfaced familiar interaction patterns while revealing fragmentation across tracking, guidance, and progress.
Journey synthesis
Six phases trace goals, thoughts, emotion, behaviors, workarounds, pain points, and opportunities from starting treatment through thinking about the future.
Research synthesis
The start needs confidence.
Participants frequently entered treatment feeling hopeful, excited, and nervous. Onboarding needed to establish a useful routine without overwhelming people with every possible setting.
Progress needs context.
Weight alone could not tell the complete story. Timing, dose, symptoms, and treatment milestones needed to remain close enough to reveal a coherent pattern.
Support must stay nonjudgmental.
The interface needed to communicate urgency without shame and acknowledge missed or delayed routines without turning the product into a compliance score.
One glance should orient the user.
The next shot and current supply emerged as orientation anchors: the fastest way to answer “where am I in the routine?” before deeper exploration.
Product system
A simple interface required a carefully connected information model.
I organized the product around five connected domains: treatment setup, shot events, medication supply, progress signals, and ongoing learning. That structure lets each screen stay focused while the system retains the context needed to guide the next action.
01
Treatment profile
02
Next shot
03
Log event
04
Progress
05
Supply
Shared treatment state
Timing · medication · dose · symptoms · inventory · goals
01
Orient
Make the next treatment action and its status visible before asking the user to interpret charts or history.
02
Connect
Treat shots, symptoms, progress, and supply as related evidence rather than independent logs.
03
Translate
Turn medication and inventory rules into plain-language actions while preserving provenance and refusal states.
04
Reassure
Use calm feedback, forgiving flows, and local-first privacy to support confidence without false clinical authority.
Planning the product
The architecture and roadmap turned a broad opportunity into buildable decisions.
The roadmap separated understanding, core tracking, launch-and-learn, and premium expansion. In parallel, the information architecture described conditional states for onboarding, summary, logging, progress, goals, reports, reminders, learning, and account management.
Phased roadmap · research to release
Information architecture · screens and states
Experience decisions
The interface turns system state into a sequence of clear decisions.
01 · Orient
Start with the next shot, then reveal the wider treatment picture.
Summary prioritizes the time-sensitive action and keeps medication level, recent shots, weight, and side effects within the same scan. The hierarchy answers “what is next?” before “how am I trending?”
A
Status before analytics
The bird character changes with shot state, creating an immediately recognizable cue for upcoming, due, logged, and overdue moments.
B
Contextual overview
Trend cards summarize the most relevant state and route into detail without turning the home screen into a dashboard of charts.
02 · Connect
Logging a shot updates more than history.
A shot event connects medication, dose, time, preferred injection region, supply source, pain, side effects, and notes. That single event can then update the next-shot calculation, treatment trend, supply state, and progress context.
The review-first pattern gives users one place to verify clinically sensitive details before saving, while “Change” actions preserve control without forcing a long linear form.
03 · Sustain
Progress and learning extend the product beyond shot day.
Weight and medication trends provide longitudinal context, while a five-chapter learning journey supports realistic goals, planning, behavior change, special occasions, and maintenance.
The system is intentionally progressive: users see what is available, what comes next, and why later chapters are locked without exposing the entire curriculum at once.
Build and verification
I carried product rules through code, motion, tests, and native platform behavior.
Next-shot interaction · product source
Health report interaction · product source
Domain logic
Vial guidance fails closed.
The calculation engine converts a saved dose and physical vial concentration into a supported syringe position, rounds only to printed graduations, identifies approximation, preserves calculation provenance, and refuses guidance when inputs conflict or exceed capacity.
Inventory model
Supply reflects real-world mess.
The model accounts for active and unopened containers, remaining medication, expiration or beyond-use dates, refill risk, inventory corrections, and differences between the current treatment and what is physically on hand.
Platform continuity
The routine extends beyond the app.
Apple Health integration supports weight context, while Apple Watch surfaces expose next-shot and active-supply information for fast checks. Local-first storage keeps sensitive treatment records on the device without requiring an account.
Quality gates
Trust is built into delivery.
Strict TypeScript checking, linting, unit tests, dead-code scanning, Watch integration verification, and device QA form the release gate. The most sensitive logic is tested at boundaries, invalid inputs, storage round-trips, and state changes.
10
injectable medications represented in the built-in catalog.
246
automated tests passed at completion of the vial-guidance milestone.
2
native platforms connected through iPhone and Apple Watch surfaces.
Founder operating system
I kept one product model intact from evidence through release.
I worked through one continuous loop. User evidence changed the information model, the model shaped interactions and treatment logic, device QA exposed new product decisions, and each verified build became evidence for the next release.
STEP 01
Listen
Survey evidenceSTEP 02
Frame
Story mapSTEP 03
Architect
State modelSTEP 04
Design
PrototypeSTEP 05
Build
Product codeSTEP 06
Verify
Device QA↩ evidence returns to the next cycle
One founder, one connected loop, from unmet need to tested release.
06
Outcome
A working product foundation with depth beyond the interface.
Implemented
ShotNest now supports personalized onboarding, local reminders, shot and side-effect logging, progress trends, supply tracking, vial workflow guidance, Apple Health integration, Apple Watch status surfaces, and a structured learning journey.
Capability demonstrated
The work demonstrates end-to-end product practice: framing a complex health-management problem, translating research into architecture, designing the interaction system, implementing native behavior, testing sensitive logic, and preparing a release.
Evidence boundary
This case study distinguishes implemented capability from market outcome. App Store performance, adherence improvement, and clinical efficacy are intentionally not claimed without corresponding evidence.
Next evaluation
Post-release evaluation should focus on successful routine setup, shot-logging completion, correction frequency, reminder reliability, supply accuracy, and whether users can explain their current treatment state without consulting another tool.
The product’s central promise remains simple: know what happened, what is next, and whether you are ready.
Visit ShotNestInterface gallery
The story explains the decisions. The gallery shows the breadth of the work.
Showing 11 of 18 views. Open any image to inspect it at full size.
Summary · Treatment status and next shot
Medication trend · Estimated treatment level
Log shot · Review before saving
Supply · Remaining medication and refill timing
Progress · Weight history in treatment context
Learn · Progressive treatment education
Discovery · User story map connecting activities, steps, and stories
Discovery · Comparative review of GLP-1 tracking products
Discovery · Journey map from treatment start through long-term maintenance
Planning · Research, core build, launch, and ShotNest+ phases
Planning · Detailed product and state architecture
