The Problem
I started with a familiar health-tracking product. It could log information, but the product had no clear reason to exist beside Apple Health, MyFitnessPal, or a telehealth app.
The problem was not a lack of features. It was a weak product thesis.
Decision: Stop adding features. Go back to the market and find a narrower problem worth solving.
Market Research
I mapped pure trackers, behavioral programs, telehealth products, and GLP-1 tools. I reviewed more than 60 reference screens and translated the work into personas, product requirements, a business model, and a regulatory plan.
The research surfaced four gaps that were more specific than generic tracking:
Product Strategy
I did not try to ship every opportunity from the research. For the MVP, I chose a smaller wedge: help users record key parts of a GLP-1 journey, see progress over time, and understand basic context around the information they enter.
I also set clear product boundaries. Daybreak is an informational companion. It does not diagnose, prescribe, or tell a user how to take medication.
Privacy was part of the product thesis.
The current MVP has no accounts and no application server. User-entered data stays in the browser on the device.
This was a deliberate trade-off. It reduced privacy risk and let me test the core experience before adding the complexity of cloud storage, identity, or synchronization.
Record, do not prescribe
The medication flow records user-entered events. It does not recommend a medication or dose.
Context, not diagnosis
BMI and projection views include clear limits and are presented as general information, not clinical conclusions.
Ranges, not promises
The projection view presents a range based on published research and states that individual results vary.
Local first
The first product keeps data on-device while the value proposition is still being tested.
The Product
The working product turns the strategy into a small set of connected workflows: daily logging, treatment history, progress, body-mass context, and projections.
Result
Daybreak moved from a generic tracker to a deployed product with a clearer reason to exist. The work now connects market research, product requirements, business model decisions, privacy choices, risk boundaries, interaction design, and implementation.
The most important output was not the number of screens. It was the change in direction: I stopped building a broad tracker and used evidence to define a more focused product.
This project demonstrates market analysis, opportunity selection, product strategy, privacy-first product judgment, health-product risk awareness, and the ability to carry a thesis into a working product.
Next Steps
The next stage is validation, not more feature volume.
Test with target users
Validate whether the daily log, journey, and projection views solve problems people actually care about.
Test comprehension
Check whether health context and projections are clear without creating false certainty.
Validate clinician sharing
Test whether a concise export would improve healthcare conversations before building a full reporting workflow.
Review the data model
Only add accounts or cloud sync if the user value is large enough to justify the extra privacy and security burden.