--- id: BuildGreatProducts/builder-os/launch-checklist version: "65eda7ce" license: MIT install: manual updated: 2026-07-07 --- # launch-checklist — Launch Checklist audits your codebase to identify everything needed for production, then generates a personalized deployment guide in plain language. Each step is marked as your responsibility, your agent's task, or a collaboration, with all technical terms explained for non-technical founders. The result is a clear path from working code to customers using your product. Publisher: BuildGreatProducts · Stars: 168 · Updated: 2026-07-07 Install (manual): `git clone https://github.com/BuildGreatProducts/builder-os` ## SKILL.md # Launch Checklist This skill turns "the app works on my machine" into "customers can use it." It reviews the actual codebase, works out everything standing between the current state and a live product, and writes a personalised, step-by-step guide the founder can follow without a technical background. The voice is a patient senior engineer onboarding a smart non-technical founder: plain language, no unexplained jargon, never condescending. The founder is capable — they just haven't done this before. ## Step 1: Audit the codebase Read the repository thoroughly before writing anything. Establish: - **What the product is and where it runs** — web app, mobile app (App Store / Google Play), desktop, or a mix. Detect the framework, backend, database, auth, and payment providers from the code and dependencies — don't ask the user things the code answers. - **Configuration state** — environment variables used in code vs. what's documented (`.env.example` or similar), hardcoded values that must become secrets, test/sandbox keys that need live equivalents. - **Third-party services** — every external service the app calls, and what each needs in production (live API keys, webhook endpoints, billing enabled). - **Deploy readiness** — existing deploy config (e.g. `vercel.json`, `Dockerfile`, `eas.json`), build scripts, whether the production build currently succeeds, test status. - **Launch gaps** — things customers-facing products need that the code may lack: error tracking, analytics, legal pages (privacy policy, terms), a custom domain, database backups, app store assets for mobile. Confirm the picture with the user in one short message (product type, stack, the services found) plus any genuinely unanswerable questions — e.g. do they own a domain, do they have accounts with the detected services, is there a launch deadline. ## Step 2: Write `docs/launch-checklist.md` Write the guide to `docs/launch-checklist.md` (create the folder if needed). Structure: **Header** — product name, detected stack in one plain-English sentence, estimated total time, and a legend: - 🧑 **You** — needs your identity, accounts, payment details, or a decision. An agent can't (or shouldn't) do this for you. - 🤖 **Agent** — paste the given prompt into your coding agent and it can do this in the codebase or via the command line. - 🤝 **Together** — the agent prepares it, you click the final button or paste in a value. **Phases, each with checkbox steps.** Adapt to what the audit found — typical shape: 1. **Accounts and prerequisites** — sign up for the hosting platform and each production service; choose the cheapest tier that works, with monthly cost noted. 2. **Secrets and configuration** — create live API keys, set environment variables on the hosting platform, remove test keys. Never paste secrets into chat or commit them to code — say this explicitly. 3. **Production services** — database in production mode, auth configured for the real domain, payments switched from test to live (including webhooks and a real test purchase), email/AI/storage services on live credentials. 4. **Deploy the app** — the path of least resistance for the detected stack. For mobile: developer accounts, store listings, build submission, and an honest note that store review takes days and may need fixes. 5. **Domain** — buy/connect the domain, DNS setup, confirm HTTPS. 6. **Pre-launch verification** — a smoke test written as a user journey: sign up as a real customer, walk the core flow end to end, make a real payment and refund it, check it on a phone. 7. **After launch** — error tracking, analytics, database backups, and where to look when something breaks. **Every step must have:** - A checkbox, a 🧑/🤖/🤝 marker, and a time estimate. - Plain-language instructions. Explain every technical term inline on first use — e.g. *"DNS (the address book that points your domain name at your app's server)"*, *"environment variable (a setting stored outside your code, used for secrets like API keys)"*, *"webhook (a way for one service to automatically notify another when something happens, like a successful payment)"*. - For 🤖 steps: a ready-to-paste prompt for the coding agent, in a quote block. - For 🧑 steps: exactly where to click/go, what they'll be asked for, and any cost. - A "**You'll know it worked when...**" line so the founder can verify each step without guessing. ## Step 3: Walk the user in Don't just drop the file. Present a short summary in conversation: how many steps, the few 🧑 items they personally must do, total estimated cost per month, and the recommended first step. Offer to execute the first 🤖 step now. ## Rules - Be honest about cost, time, and risk — store review delays, DNS propagation ("can take up to a day"), payment provider verification. - Recommend one path, not a menu. The audit chose the stack; the guide commits to the matching deployment route. - Never instruct the user to share secrets in chat; secrets go directly into the hosting platform's settings. - If the audit finds blockers (failing build, hardcoded secrets, no payment webhooks), the guide's Phase 0 is fixing them — each as a 🤖 step with a prompt. - The product isn't "deployed" until the smoke test passes as a real customer. [View on SkillFed](https://skillfed.io/BuildGreatProducts/builder-os/launch-checklist) · [View on GitHub](https://github.com/BuildGreatProducts/builder-os)