Instrument before you troubleshoot
Three external CFIs signed up to Trim. Zero have flown a lesson through it. For two months I shipped UX guesses at the activation problem. Today I finished wiring the instrument the airplane was missing.
The activation problem is the only problem at Trim right now. Three external CFIs have signed up to the product. None of them have logged a real lesson through it. The first one — call him CFI Alpha — completed onboarding and went silent inside three days. The next two never added a student. Everything else — the dashboard, the chip system, the email theme, the calendar — is downstream of that.
For two months I shipped UX guesses at it. Auto-open the AddStudent modal after onboarding. Hoist the Getting Started checklist above the empty cards. Persist the aircraft step instead of letting it discard. Each one was a defensible guess. None of them moved the number. There is a reason none of them moved the number, and the reason is that I was guessing.
You can't fly partial-panel with your eyes closed
Phase 14 added the table. It built cfi_page_events — every CFI's page visits, key actions, attribution — and the daily cron that summarizes it back to me. But the onboarding wizard, the part where every CFI actually drops off, was firing exactly one event: dashboard.visited. The seven steps in between were dark. The lesson-booking flow was dark. The lesson-completion flow was dark. The table was there. We just hadn't wired any sensors to it.
So the question I'd been asking — "why did CFI Alpha bounce after 58 hours?" — was permanently unanswerable. The same way you can't troubleshoot a fuel-flow problem without a fuel-flow gauge. You can guess at the carb. You can pull the fuel selector. You can lean it harder. You will be wrong, on average, more than you are right, and you will spend hours doing it.
What got wired today
Eight events, one per step:
onboarding.started— wizard mountsonboarding.step— every forward transition, tagged from→toonboarding.skipped— explicit skip, with which steponboarding.students-added— count of students draftedonboarding.aircraft-saved— the step that used to discard now persists, and emitsonboarding.completed— done steplesson.booked— first time a CFI commits to a slotlesson.completed— both completion paths, tagged with which modal
End to end the funnel is now signup → onboarding.started → step → step → … → completed → students-added → aircraft-saved → lesson.booked → lesson.completed. The next external CFI who signs up leaves a step-by-step trail. The step they bounce from becomes a query, not a guess.
The instrument was the bug. The airplane was fine.
The discipline this enforces
The rule I'm keeping out of this is the seductive one — "ship more UX fixes anyway, the data will tell us afterwards whether we were right." That is the wrong way to use instrumentation. The way to use instrumentation is to let it pick the next fix. Three UX changes from intuition, zero movement; one change that flows from a measurement, watch the number.
For CFI Alpha specifically, the funnel is permanently silent — he predates all of this. His drop-off step is unrecoverable. That is a sunk cost. The next external CFI's drop-off step is recoverable, and the recovery starts with reading the table. Phase 20 is "read the funnel, fix the leak." Singular leak. Whichever step the data names.
Aviation is full of versions of this. You don't change a magneto on a hunch. You run the mag check, see which side drops, then change the one that's actually fouled. The activation problem at Trim now has a mag check. Two months late, but it has one.