---
name: launch-signup-check
description: Implement and test signup persistence, analytics events, and founder notifications as separate launch checks.
---

# Launch signup check

Inspect the actual signup flow and approved analytics/email integrations in the authorized codebase. Do not read credentials or use private customer records. Use a designated test identity and inbox if submission is authorized; otherwise prepare a local or mocked test and describe the unverified live steps.

Trigger analytics and the founder notification only after a successful stored signup. Preserve a stable logical signup ID, prevent duplicate submissions and retries from creating duplicate logical events, and keep personal email addresses out of analytics payloads. Separate a provider delivery attempt from actual inbox receipt. Describe consent, blocked trackers, and server/client collection limits honestly.

Verify separately: signup persisted; expected event is visible; notification accepted by the provider; message received in the test inbox; QA traffic identified; retry handling and failures observed. Do not call a script tag or HTTP 200 proof of delivery.

Return the implementation and an evidence card with result, source, time, and remaining unknowns for each check. Remove test records only within the user's cleanup authorization. Reference: https://launchbuddy.com/blog/day-two-launch-dashboard-for-mvp.