The 90‑Minute Launch README: Turn a Git Repo into a Build‑Ready Launch Package

Multiple documents — tickets, scattered docs, partial READMEs — slow down the first meaningful PR. A single Launch README acts as a canonical source of truth: the product intent, the demo narrative, required instrumentation, and the acceptance criteria. That clarity cuts ambiguity for contractors and first contributors, letting you get to working code faster.

The README is not the long PRD you draft later. Think of it as a 1‑page PRD plus operational outputs. That means explicit success metrics, a short user flow, required API surface, visible demo steps, and a telemetry map all live together so a contributor can implement, test, and submit a reviewable PR without chasing context.

Set a 90‑minute timer and run three focused passes: 1) capture product intent and acceptance criteria (30 minutes), 2) specify implementation and telemetry (30 minutes), 3) produce demo README, JSON‑LD, and finalize the contractor handoff with a checklist (30 minutes). Keep each pass time boxed — the Readme’s role is to be actionable, not encyclopedic.

During pass one, fill these fields: problem statement (1–2 sentences), target user, core job-to-be-done, one primary success metric, and the 3‑step user flow. In pass two, list the concrete API/endpoints or UI components to change, required config/feature flags, and a telemetry map mapping events to property names and desired metrics (count, unique, latency, error). In pass three, write demo steps that reproduce the value in under five minutes and paste a JSON‑LD SoftwareApplication snippet for the app landing page.

Paste this structure into README.md at the repo root. Key top‑level fields (title, owner, status, one‑line value prop, primary success metric) become your PRD header and the demo README intro. A 'Getting a local demo up' section becomes the demo README output; mark it with a branch or tag to avoid confusion.

Include a 'Structured metadata (JSON‑LD)' section. For discoverability and consistent metadata across marketing and product pages, embed a SoftwareApplication JSON‑LD block that contains name, description, applicationCategory, operatingSystem, and a download or demo URL. This small snippet helps future marketing pages and search engines understand the product entity.

The telemetry map should be a compact table inside the README: event name, trigger (UI action or backend), properties, expected aggregations, and ownership. That table is the single most valuable artifact for QA and analytics because it makes acceptance testable and aligns engineering, product, and data teams.

The contractor handoff section must end with explicit acceptance criteria and a short test plan: steps to run locally, example inputs and expected outputs, API contract snippets (request/response examples), and where to run end‑to‑end checks. Include a 'what success looks like' checklist that reviewers can tick off before merging.

Run this checklist before creating the PR so reviewers can focus on design and correctness rather than chasing missing context. If everything in the README and checklist is covered, most first PRs are small, focused, and mergeable quickly.

Keep the checklist in the Launch README and copy it to your PR template so contractors see it prefilled. Over time you’ll adapt the checklist to include organization‑specific items (security scans, license checks, product analytics gating).