Pre-launch deployment checklist for PM-builders: domain setup, SSL, environment variables, database backup, monitoring, error tracking, analytics, SEO, performance, and security basics.
From pm-vibe-codingnpx claudepluginhub tarunccet/pm-skills --plugin pm-vibe-codingThis skill uses the workspace's default tool permissions.
Searches, retrieves, and installs Agent Skills from prompts.chat registry using MCP tools like search_skills and get_skill. Activates for finding skills, browsing catalogs, or extending Claude.
Searches prompts.chat for AI prompt templates by keyword or category, retrieves by ID with variable handling, and improves prompts via AI. Use for discovering or enhancing prompts.
Guides implementation of event-driven hooks in Claude Code plugins using prompt-based validation and bash commands for PreToolUse, Stop, and session events.
⚠️ This checklist helps you prepare for deployment, but it is NOT a substitute for engineering review. Before any production deployment, ensure:
- A qualified engineer has reviewed the code
- Security review has been completed (especially auth, data handling, API keys)
- Load/performance testing appropriate to expected traffic has been done
This checklist covers what a PM-builder can verify independently. Flag items you can't verify yourself — those are the ones that need engineering support.
A structured pre-launch checklist for PM-builders deploying their first product or prototype. Covers the basics that AI-generated code often misses: environment variables, SSL, database backups, monitoring, error tracking, and analytics. Prevents the embarrassment of shipping with debug logs, exposed secrets, or no error visibility.
Most PM-builder deployment failures come from one of these: (1) secrets accidentally committed to GitHub, (2) no error tracking so you find out about crashes from users, (3) database with no backup that gets corrupted, (4) no analytics so you can't measure anything, (5) site title still says "Create Next App."
This checklist is ordered by risk — work top to bottom. The security section is not optional even for quick prototypes, because pushing API keys to a public GitHub repo can result in charges within minutes from automated bots that scan repos for exposed credentials.
The PM deployment mindset: Your goal is a "quiet launch" — a product that is live, functional, observable (you know when it breaks), and measurable (you know if people are using it). A quiet launch is better than a big launch with a broken product.
You are running a deployment checklist for $ARGUMENTS.
Work through each section systematically. Mark each item ✅ (done), ❌ (blocker — must fix), or ⚠️ (warning — should fix soon).
These are blockers. Do not share a URL publicly if any of these are failing.
grep -r "sk-" . and grep -r "secret" . to find common patterns. Everything sensitive must be in environment variables.env is in .gitignore: Open your .gitignore file and verify .env, .env.local, .env.production are listed. Run git status and confirm no .env files are staged.env file are set in the production environment settingsconsole.log statements that output sensitive data (user emails, tokens, API responses). Use a conditional: if (process.env.NODE_ENV !== 'production') console.log(...)DATABASE_URL, SUPABASE_URL, MONGODB_URI or similar in your code — they should reference process.env.*prisma migrate deploy, or apply SQL migrations in Supabase's SQL editor)You need to know when your app breaks before your users tell you.
npm install @sentry/nextjs and follow their setup wizard. Takes 15 minutes and is worth itGET /api/health endpoint that returns { status: "ok", timestamp: Date.now() }. This lets you and monitoring tools verify the app is aliveYou need to know if people are actually using the product.
posthog.capture('signed_up', { plan: 'free' })These are "done" items — small details that signal professionalism.
<title> tag in your root layout<meta name="description"> tag for SEO and social sharing previewsog:title, og:description, and og:image on the homepage<Image> component instead of <img> — it auto-optimizes images. Large unoptimized images are the #1 cause of slow page loadsThe most important section — test the actual product, not the code.
Overall Status: [Ready to launch / Not ready — X blockers remain]
Blockers (must fix before sharing URL):
Warnings (should fix within 48 hours of launch):
Completed: [N] of [Total] checklist items
Launch confidence: [High / Medium / Low] — [Brief rationale]
For a Next.js + Supabase app deployed to Vercel, before sharing with beta users:
.env.local is in .gitignore/app/api/generate/route.ts line 3 — move to OPENAI_API_KEY env var before pushing to GitHub. Cost: $0, Time: 5 minutes@sentry/nextjs before real user launch so you know when things breakmetadata.title in app/layout.tsx.vercel.app domainsignups table — anyone with the anon key can read all signups. Enable RLS and add policy: select for authenticated users onlyThe items above are what YOU can verify. The following require engineering support:
→ Share this checklist with an engineer before going live.