Some hosts allow zip uploads, but GitHub is the standard path. It enables automatic redeploys on every push and works with readiness scans.

How long does a first launch take?

45–90 minutes if you follow the phases without major blockers. Secret cleanup or deploy debugging can add time — that is normal.

What if my scan shows many warnings?

Fix critical and high-severity first. Launch when security and deploy fundamentals are solid. Low-severity items can wait.

Do I need a custom domain in Phase 5?

No. Your host's free subdomain is a valid launch. Custom domain is optional and can be added later.

How is this different from 'Is my app ready to launch?'

The readiness guide explains categories and judgment calls. This checklist is the step-by-step process. Use both — theory plus execution.

Guides

AI App Launch Checklist (Step by Step)

This is the operational checklist for launching an AI-built app — from folder on your laptop to a URL anyone can open. Work through the five phases in order. Each phase has a goal, concrete actions, and a gate before you move on. Skipping Phase 1 (protecting secrets) is the regret we hear most from first-time makers.

Updated July 2026 · 10 min read

Written for AI makers using tools like Cursor, Bolt, Lovable, Replit, Claude, and ChatGPT.

Quick answer

Launch in five phases: (1) save and protect secrets locally, (2) upload code to GitHub without sensitive files, (3) run a launch readiness scan and fix critical issues, (4) deploy to a host with environment variables set, (5) verify the live URL and optional domain. Do not skip ahead.

Who this is for

You finished building with Cursor, Bolt, Lovable, v0, or similar and want a ordered checklist
You prefer checking boxes over reading long theory guides
You want one document to follow from first save to live URL

What you'll need

Your project folder (app runs locally without crashing)
Free GitHub account and hosting account (Vercel, Railway, Render, etc.)
45–90 minutes for a first launch
List of environment variables (check .env.example)

How to use this checklist

Treat each phase as a gate. Finish every item in Phase 1 before opening GitHub Desktop. Finish Phase 2 before running a scan. Rushing to deploy with secrets in your repo or debug mode on creates recoverable-but-painful problems.

The numbered steps below expand each phase with context. The checklist at the bottom is your at-a-glance version — print it or keep it open in a second window.

If you get stuck, follow the contextual links for deep dives on GitHub, .gitignore, environment variables, and readiness. This document is the map; those guides are the terrain.

The five phases at a glance

Phase 1 — Save and protect: secrets stay local, .gitignore configured. Phase 2 — GitHub: code in the cloud, nothing sensitive uploaded. Phase 3 — Readiness scan: automated review and fix critical blockers. Phase 4 — Deploy: host connected, env vars set, build succeeds. Phase 5 — Verify: live URL tested, logs clean, optional domain.

Most first launches fail in Phase 1 or 4 — leaked .env files or missing DATABASE_URL on the host. This checklist calls those out explicitly.

Pick a host before Phase 4

You do not need to decide on day one, but before Phase 4, match your stack to a host: Next.js and static sites → Vercel or Netlify. Django and Python APIs → Railway or Render. Full-stack Node → Railway, Render, or Fly.io.

All listed hosts connect to GitHub and support environment variables in a dashboard. Avoid exotic hosts for your first launch — pick well-documented paths with beginner guides.

After you complete Phase 5

Share your URL with one trusted tester before going public. Monitor host logs for the first 24 hours. Run a second readiness scan if you fixed issues during deploy.

Optional next steps: custom domain, error monitoring (Sentry), analytics, and automated tests. None are required for a valid first launch — a safe, working URL is the milestone.

Step-by-step

1
Step 1
Phase 1 — Save and protect
Goal: your project folder is safe to upload. Nothing in the next phases should expose API keys, passwords, or multi-gigabyte dependency folders.
AI tools create .env files automatically. Open your project root and look for .env, .env.local, and any file containing sk_, pk_, or obvious passwords. If .env has real values, that is expected locally — it must never reach GitHub.
Create or update .gitignore before any Git commit. If you are unsure which patterns to use, run the safe-upload tool or ask your AI tool to generate a stack-specific .gitignore.
- Inventory every API key and secret — OpenAI, Stripe, Supabase, database URLs
- Create or update .gitignore (.env, node_modules/, .next/, .venv/, db.sqlite3)
- Confirm .env is NOT in Git's tracked files (git status or GitHub Desktop file list)
- Create .env.example with variable names and placeholder values only
- Search codebase for hardcoded secrets — move them to environment variables
- Remove or ignore local database files unless intentional
- Add a short README.md if missing (what the app does, how to run locally)
2
Step 2
Phase 2 — GitHub
Goal: your code lives on GitHub as backup and deploy source. The repo should contain source code and config templates — not secrets or node_modules.
Use GitHub Desktop, Cursor's Source Control, or the terminal — whichever you prefer. Create a new repository on github.com or publish from Desktop. Choose private if you are not ready for public code.
Before clicking Publish, review every file in the commit list one last time. If you see .env, stop and return to Phase 1.
- Create a GitHub account if you do not have one
- Initialize Git in your project folder (or add via GitHub Desktop)
- Make your first commit with .gitignore and .env.example included
- Publish to a new GitHub repository (private recommended for commercial apps)
- Open github.com/yourname/yourrepo and spot-check: no .env, no node_modules
- Copy the repository URL — you will need it for the host in Phase 4
3
Step 3
Phase 3 — Readiness scan
Goal: find launch blockers automatically before strangers hit your app. Manual review misses things in AI-generated repos with dozens of files you never opened.
Connect your GitHub repository to MakerToLaunch and run a launch readiness scan. The scan flags missing .env.example, debug mode, weak .gitignore, absent README, suspicious patterns, and dependency issues.
Sort results by severity. Fix all critical items before deploying. High-severity items strongly recommended. Low-severity polish can wait until after first launch.
Use the copy-ready fix prompts in your scan report — paste them into Cursor or your AI tool to apply changes, then push to GitHub and re-scan if needed.
- Connect GitHub repo to MakerToLaunch
- Run launch readiness scan
- Review critical and high-severity findings
- Fix top issues (debug mode, secrets, missing env template, ALLOWED_HOSTS)
- Push fixes to GitHub
- Re-scan until critical blockers are resolved
4
Step 4
Phase 4 — Deploy
Goal: your app runs on a public server with production configuration. The host pulls code from GitHub, installs dependencies, builds, and starts your app.
Sign up for your chosen host. Create a new project and connect your GitHub repository. Grant access to the repo you created in Phase 2.
Set every environment variable from .env.example in the host dashboard — same names, production values. Use production API keys where applicable. Replace any localhost URLs with your production API URL.
Configure build and start commands if the host does not auto-detect them. Trigger deploy and watch logs. 'Build failed' or 'Application error' usually means a missing env var or wrong command.
- Create account on Vercel, Railway, Render, or stack-appropriate host
- Import project from GitHub
- Add all environment variables from .env.example (names must match exactly)
- Set DEBUG=False or NODE_ENV=production for production
- Create production database if your app needs one; set DATABASE_URL
- Run migrations if applicable (Django migrate, Prisma deploy, etc.)
- Trigger deploy and wait for build to complete
- Open the host-provided URL (e.g. yourapp.vercel.app)
5
Step 5
Phase 5 — Verify
Goal: confirm the live app works for real users, not just on your laptop. This phase catches environment gaps and debug settings that only appear in production.
Open your live URL in an incognito or private browser window so cached logins do not fool you. Walk through the main user flow: sign up, create content, checkout, or whatever your core feature is.
Check host deployment logs for errors on startup and during your test. Trigger a deliberate error — you should see a friendly page, not a stack trace.
Optional: connect a custom domain (see domain and DNS glossary entries). Optional: run a final readiness scan. Then share with a small audience and iterate.
- Test main user flow on live URL in incognito
- Verify HTTPS padlock in browser address bar
- Confirm no debug stack traces on error pages
- Check host logs for startup errors or missing env warnings
- Test auth flows (signup, login, logout) on production
- Optional: connect custom domain and update ALLOWED_HOSTS
- Optional: run final readiness scan after deploy fixes
- Share URL with one trusted tester before broad announcement

Common mistakes

Skipping Phase 1 and uploading everything
How to fix it: Stop, add .gitignore, rotate any exposed keys, remove secrets from Git history, then continue from Phase 1.
Deploying before the readiness scan
How to fix it: Run the scan in Phase 3. Fixing debug mode and secrets on a live URL is stressful.
Forgetting to redeploy after adding environment variables
How to fix it: Most hosts require a new deploy for env changes. Redeploy from the dashboard after every update.
Testing only on localhost after deploy
How to fix it: Phase 5 exists because production behaves differently. Always test the host URL in incognito.
Treating the checklist as optional for 'small' projects
How to fix it: Small projects leak keys the same way large ones do. Follow all five phases even for MVPs.

Copy-ready prompt

Prompt: audit my launch readiness

Paste this into Cursor, Claude, ChatGPT, Bolt, Lovable, or your AI coding tool.

Ready to paste

Audit my AI-built app for launch readiness. Walk through all five phases:

Phase 1 — Save and protect:
- Check .gitignore covers .env, node_modules, build folders, local databases
- Confirm .env is not tracked by Git
- Verify .env.example exists with placeholders only
- Search for hardcoded API keys or passwords

Phase 2 — GitHub:
- Confirm repo structure looks safe for public or private upload
- Flag any files that should not be on GitHub

Phase 3 — Readiness:
- Check for DEBUG=True or equivalent in production config
- Verify README exists
- List missing environment variables or config gaps

Phase 4 — Deploy:
- List required environment variables for my host
- Suggest build and start commands for my stack
- Flag localhost URLs that need production replacements

Phase 5 — Verify:
- Suggest a test plan for the live URL
- List common production-only failure modes for my stack

Output a prioritized issue list with copy-ready fix instructions. Do not expose or repeat real secret values.

Paste this into Cursor, Claude, ChatGPT, Bolt, Lovable, or your AI coding tool.

Ready check

Beginner checklist

Phase 1: .gitignore includes .env and dependency folders
Phase 1: .env.example created with placeholder values
Phase 1: No hardcoded secrets in source code
Phase 2: Code published to GitHub (no .env in repo)
Phase 2: README.md describes the project
Phase 3: Launch readiness scan completed
Phase 3: Critical scan issues fixed
Phase 4: Host connected to GitHub repo
Phase 4: All environment variables set on host
Phase 4: Production database created and migrated (if applicable)
Phase 4: Deploy succeeded without build errors
Phase 5: Main user flow tested on live URL in incognito
Phase 5: No public debug stack traces
Phase 5: Host logs show no critical startup errors

Frequently asked questions

Can I skip GitHub?: Some hosts allow zip uploads, but GitHub is the standard path. It enables automatic redeploys on every push and works with readiness scans.
How long does a first launch take?: 45–90 minutes if you follow the phases without major blockers. Secret cleanup or deploy debugging can add time — that is normal.
What if my scan shows many warnings?: Fix critical and high-severity first. Launch when security and deploy fundamentals are solid. Low-severity items can wait.
Do I need a custom domain in Phase 5?: No. Your host's free subdomain is a valid launch. Custom domain is optional and can be added later.
How is this different from 'Is my app ready to launch?': The readiness guide explains categories and judgment calls. This checklist is the step-by-step process. Use both — theory plus execution.