Audit PostHog + Sentry overlap

[n-lark]

PostHog + Sentry Overlap

Both tools are wired in; their boundary was never explicitly designed. With Sentry trimmed to errors-only, worth deciding what each tool is for.

Where they overlap (observed)

• services/product.js#identify() fans the same user payload out to three tools — PostHog, Sentry (setUser), and HubSpot (_hsq). One function, three destinations, drift-prone.
• Sentry.setUser lives in services/product.js (a file named for analytics), separate from services/error-tracking.js where the rest of Sentry lives.
• Localhost filtering is inconsistent: Sentry has a SDK-level beforeSend localhost guard; PostHog has none.
• PostHog ships its own Errors product; we don't use it. Sentry's Errors is the system of record.

Questions

• Sentry-for-errors + PostHog-for-everything-else — right split, or accidental?
• Should Sentry.setUser move out of services/product.js into services/error-tracking.js?
• One identify(user) entry point that fans out, or keep explicit per-tool wiring?
• Is posthog-node (backend) actually used? For what?
• Who opens each tool's dashboard, and where do alerts land?