Launch strategy patterns

Use this reference after the main skill selects strategy, audit, implementation, or postmortem mode. Platform behavior is time-sensitive; verify current rules from official platform documentation and date the evidence.

Contents

• Positioning
• Audience access
• Launch loops
• Channel selection
• Assets and operations
• Measurement
• Postmortem

Positioning

Create a compact claim stack:

1. audience and triggering situation;
2. costly or frustrating current approach;
3. changed outcome;
4. product mechanism;
5. proof and limitation;
6. why the timing is relevant.

Test the claim against current alternatives and actual audience language. Distinguish customer words, observed behavior, and team hypotheses.

Audience access

Map real paths to the first users:

Audience cluster	Existing relationship/access	Place or channel	Native artifact	Owner	Evidence

Prefer channels where the team can participate credibly. “Developers,” “founders,” or a platform name alone is not an access strategy.

Launch loops

Describe each loop as:

trigger → artifact/message → channel → landing/context → target action → follow-up → learning

Examples of artifacts include a working demo, benchmark, template, integration, technical explanation, customer story, event, or shareable product output. Build an artifact only when it strengthens the chosen loop.

Channel selection

Evaluate channels by:

• audience concentration and team credibility;
• format fit and proof required;
• preparation lead time;
• platform and community rules;
• conversion path and follow-up capability;
• measurement quality;
• downside from low relevance or excessive promotion.

Do not claim to know ranking weights, vote thresholds, “best” launch days, or premium-account boosts unless a current official source documents them. Do not coordinate votes, fake engagement, or evade community rules.

Useful channel-specific questions:

• Community/forum: What contribution is welcome? Is self-promotion limited to specific threads?
• Directory/launch platform: What assets and listing fields are required? What solicitation is prohibited?
• Social: Which existing audience relationship and artifact make the post native?
• Email/newsletter: Is the list consented and relevant? What is the sender's follow-up capacity?
• Partners/integrations: Is the listing approved and the integration reliable enough to support demand?
• Press/analyst: Is there a genuinely newsworthy, verifiable claim and an available spokesperson?

Assets and operations

Create a dependency table:

Asset or product change	Supports which loop	Required proof/content	Owner	Due	Verification

Plan day-of operations proportionally:

• publishing/access credentials;
• response ownership and service level;
• issue intake and severity routing;
• status communication and rollback;
• customer/support handoff;
• decision checkpoints.

Measurement

For each metric define event, population, window, source, owner, baseline/target if evidence exists, and decision. Separate directional source attribution from causal lift.

Common layers:

• reach or qualified visits;
• target action;
• activation/value event;
• retention or revenue after maturity;
• operational quality and support burden.

Use tagged links consistently, preserve referrer where possible, and test event capture before launch.

Postmortem

Compare observed results with the launch hypotheses:

• what shipped and where;
• funnel counts with denominators and maturity;
• qualitative themes with examples;
• channel and message evidence;
• failures, incidents, and attribution gaps;
• positioning/product/distribution decisions;
• follow-up experiments and owners;
• reusable assets and relationships.

Do not treat a single launch-day rank or traffic spike as product-market fit.

Safe waitlist implementation

Adapt this design to the detected stack. It defines invariants and failure handling rather than paste-ready framework code.

Contents

• Decisions
• Data model
• Signup transaction
• Confirmation and consent
• Referrals
• Admin access
• Abuse and privacy
• Verification

Decisions

Infer from the product and ask only unresolved choices:

• fields strictly required for launch;
• single or double opt-in and jurisdiction/product rationale;
• confirmation email and sender setup;
• referral program and fraud tolerance;
• queue position semantics, if positions are shown at all;
• admin/export users and retention/deletion policy.

Email-only is often lower friction, but it is not a universal requirement.

Data model

Preserve these logical fields as required by the chosen design:

id: random opaque identifier
normalized_email: unique under an explicit normalization policy
display fields: optional, length-limited, safely encoded on output
status: pending | confirmed | unsubscribed | deleted
consent_source / consent_version / consent_at: when required
confirmation_token_hash / expiry: for double opt-in
referral_code: cryptographically random and unique
referred_by_id: validated foreign key
created_at / confirmed_at / unsubscribed_at
source and campaign fields: allowlisted, length-limited

Do not expose sequential IDs or derive public referral codes from email. Avoid mutable queue positions unless the product has a clear, concurrency-safe ordering policy.

Use database constraints for uniqueness and referential integrity. Treat the database as the authority under concurrent requests.

Signup transaction

The handler should:

1. enforce request size/content type and parse safely;
2. validate and normalize the email under a documented policy;
3. validate/limit optional text and attribution fields;
4. apply rate limiting and bot/abuse controls appropriate to exposure;
5. insert with an atomic upsert or catch the unique constraint;
6. validate referral code and record attribution transactionally;
7. return a generic success response that does not reveal whether an arbitrary address is registered;
8. enqueue confirmation delivery after durable storage;
9. emit privacy-minimized success/failure events.

Do not perform “check then insert” as the uniqueness mechanism. Do not increment referral counters separately from the referral record; derive or update them transactionally.

Confirmation and consent

• Use a cryptographically random, single-use, expiring token; store only its hash.
• Encode user-supplied content in HTML and provide a text version.
• Use a verified sending domain and current provider guidance.
• Handle provider failure asynchronously with retries and idempotency.
• Include required sender identity and preference/opt-out controls.
• Do not activate referrals, queue movement, or campaigns until the chosen confirmation rule is satisfied.
• Keep consent evidence separate from marketing assumptions. Joining a product waitlist does not automatically authorize unrelated messages.

Referrals

Model each accepted referral as an idempotent relationship. Prevent:

• self-referral;
• repeated credit for the same confirmed signup;
• credit before confirmation when confirmation is required;
• arbitrary client-supplied referrer IDs;
• easily enumerable or guessable codes;
• unbounded rewards without fraud review.

Define what happens when a referrer unsubscribes or a referred user is deleted.

Admin access

Use the application's real authorization system with a least-privilege admin role. A static secret header is not a substitute for an admin surface.

Admin/export behavior should include:

• server-side authorization on every request;
• pagination and field minimization;
• audit logging for view/export/delete;
• CSV/formula-injection protection on export;
• rate limits and short-lived download links where applicable;
• retention, deletion, unsubscribe, and data-subject workflows;
• no raw PII in application logs or analytics.

Abuse and privacy

Document data purpose, fields, processors, retention, access, deletion, consent basis, and incident path. Add CSRF protection when cookie-authenticated state changes require it. Review spam traps, disposable addresses, automated signups, and referral gaming in proportion to risk.

Verification

Test locally and in the deployed environment:

• valid, invalid, Unicode, case, whitespace, and maximum-length addresses;
• concurrent duplicate submissions;
• generic response for existing and new addresses;
• rate-limit and bot-control behavior;
• confirmation token expiry, reuse, and wrong-token cases;
• email HTML/text encoding and deliverability;
• referral validation, idempotency, self-referral, and confirmation gate;
• admin authorization, pagination, export safety, audit log, and deletion;
• analytics events without PII;
• provider outage, retry, and recovery;
• accessibility, loading, error, success, and offline states.