Dashboard

1/ Before writing a single line of analytics SDK code, I made Claude help me write a document deciding *what* to measure — and sign off on it like a contract. Turns out that decision is way harder than it sounds. 2/ The app is a property reconfiguration tool. It has AI renders, PDF generation, Land Registry lookups — several expensive operations that fire automatically on mount. My old project tracked everything as button presses. Easy. This one doesn't work that way. 3/ The core question: if something fires 6 times automatically just because a screen loads, do you track it? The rule we landed on: a feature event marks *user intent*. Auto-fires are excluded. Sounds obvious in hindsight, but it took a while to get there. 4/ The other gotcha: Expo Router has no equivalent of the automatic screen-view tracking I used in my Next.js app. So screen_view has to fire manually — and has to emit the route *pattern* (/property/[id]) not the resolved path, because the resolved path leaks tenant UUIDs. [VERIFY before Phase B] 5/ The output is a signed-off event list: base screen_view + sessions, identify() keyed on the auth user ID, 10 named feature events, 2 lifecycle events. That list is now a contract. Phase B (actually wiring the SDK) is gated on it. 6/ The other thing I didn't expect: writing the plan exposed a gap I hadn't noticed. Bug reports in this app never open a GitHub Issue — so the analytics dashboard that's supposed to surface bug trends can't see them at all. Separate problem, but I wouldn't have found it without doing this first. 7/ Doing the measurement design before the measurement code felt backwards at first. It wasn't. The document forced decisions that would have been invisible if I'd just started instrumenting. All of this drafted with Claude Opus 5. I wrote zero code this week and still shipped something real. /