Validation · do this before building

Validation to-do

The whole venture rests on one thing — we prove it cheaply, in the right order, before writing product code. Target: a confident go / park / kill in ~3 months for under $5k. Tick items; progress and verdict save in this browser.

◆ The one make-or-break
Can we predict flares accurately enough — from patient self-report — that patients will pay for it?

It splits into two, tested in order: (A) Demand — do patients want & pay for flare prediction? (B) Feasibility — can flares be predicted from self-report above baseline? Demand is cheap; feasibility is the existential one — so we de-risked it with the literature first (done), then a real cohort.

The decision tree
Demand ✅ + Feasibility ✅ → build Flarewise as designed (the compounding-moat mission-unicorn).
Demand ✅ + Feasibility ❌ → prediction moat is dead. Fallback: tracking + community + care-routing brand (real, but weaker — no unique data moat). Decide worth-it or pivot.
Demand ❌ → stop. Re-test positioning once, else patients won't pay — kill before the cohort spend.
Verdict
After the gates: pursue seriously, park, or kill?
▲ GO — pursue
Both gates green. One of the 2–3 we commit to.
⏸ PARK / pivot
Demand yes, prediction no → weaker tracker-brand fallback. Decide later.
✕ KILL
Demand fails. Stop before the cohort spend.
~3 mo
to a confident go / no-go
< $5k
total (mostly the cohort)
0
product code before both gates pass
FLAREWISE · validation · gate before build · health mission-unicorn · noindex