VibeLaunch Framework

Ship vibe-coded apps safely.

VibeLaunch Framework is an open-source, plain-English guide for getting an app from idea to live production safely. It is built for solo builders, indie hackers, AI-assisted developers, vibe coders, and non-expert developers who want a practical path to launch without drowning in platform jargon.

This repo is also an audit standard for AI agents. You can point an agent at this repository and say:

Check my project against VibeLaunch Framework and tell me what I am missing before launch.

The agent layer is designed so the user does not need to fill out a separate project profile first.

Live docs: https://jackygohsg.github.io/vibelaunch-framework/

Start in 60 seconds

• New here? Start with S1. Start here.
• Want the shortest route? Use S2. Quick start.
• Already partway through? Jump to S5. What you already have.
• Want an agent audit? Use agent/prompts/audit-project.md.

What this project is

• Open-source docs for shipping an app safely
• A branching playbook that lets readers skip ahead when they already finished something
• An agent-readable audit layer with reusable prompts, evidence guidance, and machine-readable checklists
• A GitHub-friendly docs repo that can also be served as a static docs site

Who this is for

• Solo builders shipping their first real app
• Indie hackers trying to avoid obvious launch mistakes
• AI-assisted developers who can build features faster than they can judge production risk
• Non-expert developers who want plain-English guidance before they go live

How navigation works

This guide is meant to feel more like a gamebook than a textbook.

You can use it in three ways:

1. Guided beginner path
2. Jump by checkpoint
3. Solve one problem

Every important page has a short code so people and agents can refer to it quickly.

• S = Start
• P = Path
• F = Foundations
• H = Hosting
• D = Domain
• R = Ready / release
• C = Security
• T = Troubleshooting
• E = Examples
• B = Branches and skip-ahead pages

Examples:

• S1. Start here
• S2. Quick start
• S4. Choose your path
• F1. Put your code on GitHub
• H2. VPS path
• R8. Launch checklist
• T1. App works locally but not online

Branch pages help people skip ahead:

• Already have GitHub? Go to B1. Already have GitHub.
• Already running locally? Go to B2. Already running locally.
• Already have a server? Go to B3. Already have server.
• App already online but messy? Go to B12. App already online but messy.

Default recommended path

If you want the shortest sensible route, start here:

1. S1. Start here
2. S2. Quick start
3. S4. Choose your path
4. F1. Put your code on GitHub
5. F4. Run your app locally
6. H1. Choose hosting
7. H6. Deploy your app
8. D2. Set up Cloudflare
9. D3. Point your domain to your app
10. R8. Launch checklist

If your app is already live but feels fragile, skip the normal path and start with B12. App already online but messy.

Agent audit layer

The agent/ folder turns this repo into a reusable launch audit standard.

• agent/README.md explains how agents should use the repo
• agent/prompts/audit-project.md is the reusable general audit prompt
• agent/prompts/prelaunch-audit.md is the stricter launch gate prompt
• agent/prompts/missing-pieces-check.md is the short obvious-gaps prompt
• agent/checklists/*.yaml contains machine-readable checks for common launch basics and app-type-specific risks

The reporting model is intentionally honest:

• Found
• Likely missing
• Could not verify
• Launch blockers
• Highest priority fixes

Run the docs locally

Requirements:

• Node.js 20 or newer
• npm

Commands:

npm install
npm start

Build the static site:

npm run build

Run the full repo checks:

npm run check

Contributing

This is a docs-first repository. Good contributions are usually one of these:

• make a page clearer
• add a useful branch page
• improve a checklist item so an agent can verify it better
• add a realistic example stack
• fix broken links or weak crosslinks

Start with CONTRIBUTING.md and browse good-first-issues.md.

Philosophy

This project is built around a simple idea:

Builders should be able to ship safely before they understand every piece of infrastructure.

That means:

• plain English first
• technical detail second
• opinionated defaults
• real-world goals instead of tool jargon
• practical next steps instead of vague theory

If you want formal enterprise platform documentation, this is not that. This repo aims to feel more like a trustworthy builder friend helping you ship.