Run a real experiment on yourself

The idea

People constantly run bad experiments on themselves. They stop drinking coffee after 2pm, feel better for three days, and conclude it worked. This app makes the experiment real: you pick one thing you can turn on and off (magnesium at night, no screens after ten, 20mg instead of 40mg), pick one outcome your phone already measures (sleep duration, resting heart rate, step count, HRV), and it assigns each day to treatment or control at random. After four weeks it runs an actual test on the two groups and tells you whether the difference is bigger than your own day-to-day noise.

The key move is that the user never chooses which days are treatment days. The app does, the night before, and tells them that morning. That one constraint is what separates a trial from a diary.

Why build this

The quantified-self market is full of apps that log and chart, and almost none that infer. A chart of sleep against "took magnesium" is confounded by every other thing in a life: the app shows a correlation, the user reads a cause. Meanwhile the hard part — collecting the outcome data — is already solved by the watch they're wearing. HealthKit and Health Connect hand you sleep stages, resting heart rate, HRV, and activity at daily granularity, for free, with the user's consent and no hardware to build.

The audience is narrow but motivated and used to paying: people managing a chronic condition, people on a supplement stack they're not sure about, people whose doctor said "try it and see". There is also a real upstream market — researchers running decentralized trials need exactly this scaffolding — but that's v3, not v1.

Stack sketch

• Swift and SwiftUI for iOS first; the watch-wearing, supplement-buying user skews heavily iPhone.
• HealthKit for outcome data. Kotlin plus Health Connect for the Android port later, behind the same trial schema.
• All data stays on-device: SQLite via GRDB, no account, no sync server. This is both a privacy stance and a way to stay out of HIPAA-adjacent territory.
• Randomization and statistics in a small pure-Swift core so it's unit-testable: block randomization in blocks of four days, then a Mann-Whitney U test on the daily outcome plus a Hodges-Lehmann estimate for effect size. Non-parametric, because sleep and HRV distributions are skewed and n is tiny.
• A washout rule per trial type (skip the first day after a switch for anything with a half-life) configured as data, not code.
• Local notifications via UNUserNotificationCenter for the morning assignment and the evening adherence check-in.
• Charts via Swift Charts; a PDF export via ImageRenderer so a user can hand the result to their doctor.

Scope for v1

In:

• A library of maybe fifteen pre-built trial templates, each pinning an intervention, an outcome metric, a trial length, and a washout period.
• Nightly randomized assignment, a morning push telling the user which arm they're in, and a one-tap evening confirmation that they complied.
• A results screen that reports the effect, the confidence interval, how many days were usable, and a plain-language verdict — including "not enough signal", which should be the most common answer.
• PDF and CSV export.

Out: custom trials from scratch, subjective outcome scales, multiple simultaneous interventions, any social or sharing feature, Android, and anything resembling advice about what to try.

Where it could go

The obvious expansion is subjective outcomes — a one-question morning rating for mood, pain, or focus — which unlocks everything HealthKit can't measure and probably doubles the addressable set of trials. It needs care, because self-reported outcomes with an unblinded intervention are where placebo effects live; the honest version shows the user how much of their result could be expectation.

Past that, the interesting direction is aggregation without surveillance. If a thousand people run the same magnesium template, the distribution of their individual effects is genuinely useful, and it can be collected with differential privacy or simple on-device aggregation without ever shipping a single person's daily data. That turns the app from a tool into a slow, cheap observational study, and gives a reason for research groups to license the trial engine rather than rebuild it.

Watch out for

The App Store will read anything that measures an intervention against a health outcome as a medical app, so every string in the UI has to describe the user's own data and never imply a diagnosis or a recommendation — budget real time for review rejections. The deeper risk is statistical: with 28 days and a noisy outcome you can only detect large effects, and an app that keeps saying "inconclusive" is honest but churns. Show the detectable effect size up front, before the trial starts, so the user agrees to the limits in advance.