# Telethryve Launch Readiness

This document hardens the public-launch boundary for Telethryve and keeps the
repo, the app, and the campaign materials aligned.

## 1. Launch Posture

Telethryve is launchable as a builder-first, configurable product. It is not a
promise that every machine-local skill will work identically on every host
without local setup.

Public launch rules:

- only promise workflows that are configured and validated for the target
  environment;
- treat phone, email, browser, and local automation as skills with an explicit
  setup boundary;
- keep high-trust modes opt-in and visible;
- keep the copy honest about what is local, what is cloud, and what depends on
  third-party services.

## 2. Phone And Other Local Skills

Phone workflows can be marketed when the phone skill is hardened, configured,
and tested for the launch environment. The long-term engineering gap analysis in
`docs/PHONE_AGENT_DESIGN_GUIDANCE.md` is a roadmap document, not a blanket
customer promise for every launch build.

The same rule applies to other machine-local skills and tools generated by the
coding app: they may need local modification, credentials, permissions, or
operator review before they are reliable on a given host.

## 3. Pricing And Billing

Launch surfaces should agree on these rules:

- `/plans` shows the current plan catalog and Stripe pricing when the licensing
  service is configured;
- `/download` hosts the free-trial download;
- `/pricing` is the primary subscription plan selection page after trial;
- `/buy <plan>` opens Stripe Checkout;
- `/billing` sends the customer to Stripe for cancellation, plan changes,
  payment methods, and invoices;
- landing pages and release collateral should mirror the same plan names and
  pricing that Stripe is currently selling.

## 4. Policies That Must Be Linked

Every public release should link:

- [CUSTOMER_TERMS.md](../CUSTOMER_TERMS.md)
- [PRIVACY.md](../PRIVACY.md)
- [BILLING.md](../BILLING.md)
- [SUPPORT.md](../SUPPORT.md)

## 5. Production Operations

Before public launch, the licensing service should have:

- hosted deployment behind HTTPS;
- managed secrets for Stripe, SMTP, and signing keys;
- backup and restore procedures for `licensing.sqlite3` or the production data
  store that replaces it;
- health checks, uptime monitoring, and alerting for the licensing service;
- Stripe webhook monitoring and replay procedures;
- SMTP delivery monitoring for activation emails;
- an incident owner and a short runbook for payment, activation, or webhook
  failures.

## 6. Proof Boundary

Modeled strategy data and illustrated screenshots are useful internal material,
but they are not customer proof.

Before broad public launch:

- pair the campaign with at least one live demo clip or real operator capture;
- avoid presenting modeled scenario simulations as telemetry;
- replace or supplement mock screenshots in launch collateral with real product
  captures when available;
- only use testimonials, case stories, or claims that can be supported.

## 7. Instrumentation

Launch surfaces should capture at least:

- landing page view;
- primary CTA click;
- pricing CTA click;
- trial download click;
- setup-guide click;
- `/trial` start;
- `/buy <plan>` initiation by plan;
- checkout success;
- activation success;
- `/billing` open;
- retention events such as repeat usage, project resume, and renewal.

The repo campaign page includes lightweight CTA instrumentation hooks so the
published launch surface can connect them to the analytics system of choice.

## 8. Current Remaining Launch Tasks

The four public Stripe plans are now configured in the repo and reflected on
the campaign pricing surface:

- `monthly`: $9.99 per month
- `quarterly`: $26.99 every 3 months
- `semiannual`: $45.99 every 6 months
- `annual`: $100.00 per year

Before launch, the remaining work is:

- set `LICENSE_APP_BASE_URL` in the real runtime environment so Stripe billing
  portal actions return to a public account or launch page;
- set `LICENSE_SITE_BASE_URL` plus either `LICENSE_DOWNLOAD_URL` or
  `LICENSE_DOWNLOAD_FILE` for the public free-trial download;
- state the real support model plainly on the launch page and in release or
  sales material: no staffed help desk by default, technical issues are
  self-serve, and customers can use Codex or Claude Code to inspect and adapt
  their environment;
- deploy the licensing service behind HTTPS with managed secrets, backups,
  health checks, webhook monitoring, SMTP monitoring, and a short incident
  runbook;
- connect the campaign instrumentation hooks to analytics and verify the key
  conversion events;
- replace or supplement mock visuals with at least one live product capture or
  demo clip;
- run a production smoke test for `/download`, `/pricing`, checkout success,
  `/activate <token>`, `/plans`, `/buy <plan>`, and `/billing`.