Founder runbook

What is a founder runbook?

A founder runbook is a document that tells you, the founder, how your app actually works and how to keep it running. It covers the moving parts, where the data lives, which outside services it depends on, how logins work, and the steps to take when something goes wrong.

Think of it as the manual you wish came in the box. You built the app with AI, but the AI never handed you an operating guide. The runbook fills that gap in language you can read.

It's deliberately practical: less "here is the architecture" and more "here is what this app is, here is what to check first, here is what to tell a developer if you get stuck."

How is it different from a devops runbook?

A traditional devops runbook is written by engineers, for engineers, to handle incidents at scale: alert thresholds, on-call rotations, database failovers, terminal commands. It assumes deep technical fluency.

A founder runbook covers the same territory of "how do I operate this" but for a non-technical or semi-technical builder. It names the same systems in plain English and stops short of assuming you can drop into a terminal at 2am. Where a devops runbook says kubectl rollout restart, a founder runbook says "this is hosted on Replit; here's the button to restart it, and here's when you'd need to."

What does Explain My Build's free runbook contain?

Explain My Build reads your source code and generates a founder runbook for free. It typically includes:

• What this app is — a plain description of what you built, derived from the code.
• How it's wired — the main pieces and how they connect (front-end, back-end, database like Supabase, outside services).
• Secrets and settings — where environment variables and API keys are expected, so you know what not to expose.
• What to check first — the common things that break and where to look.
• Handoff notes — what a developer would need to take over, which makes it your handoff document.

Every claim is cited to a real file. If the code doesn't support a statement, the runbook flags it or leaves it out rather than guessing.

Why it matters if you built with AI

AI builders like Bolt, Lovable and Claude Code produce a working app fast, but they don't leave you an operating manual. Six weeks later you can't remember which service sends your emails or where a setting lives, and if you want to hire help you can't explain the app you own.

The runbook is the fix for both problems: it's your reference when you operate the app, and it's most of what a developer needs when you're ready to hand it off.

Get your free runbook

Point Explain My Build at your repo and you get the founder runbook plus a code-verified fix-list for free. public repositories are cloned into an isolated temporary job directory and scheduled for deletion after processing; Private GitHub uses the documented transient relay, local folders and ZIP files are read in browser memory, and CLI analysis runs locally. A configured remote model may receive derived evidence.

Start at document your AI-built app, see how it works, or run it now at the app.