How to document your AI-built app

What does it mean to document an AI-built app?

Documenting an AI-built app means turning the code an AI tool wrote for you into plain-English answers for two audiences: the people who use your app, and you, the person who has to run and extend it. Most founders who built with Lovable, Bolt, v0, Replit, Cursor, Windsurf, Base44 or Claude Code have a working product but no idea how to explain it, because they never wrote a line of it themselves.

There are two honest ways to produce documentation, and they are not equal:

• From a screen recording. You click through your app while a tool watches, then it writes steps from what it saw. This works, but it only knows the screens you happened to visit and the buttons you happened to press.
• From the code. A tool reads the real source, so it can describe every route, form, setting and edge case the AI actually built, including the ones you forgot exist.

Explain My Build takes the second path. It reads the code and grounds every claim in the file and line it came from. If it can't verify something, it flags it or refuses to say it rather than guessing.

How does documenting from code work, step by step?

The method is the same regardless of which AI tool built your app, because in the end they all produce code. Here is the shared process:

1. Point it at your code. Paste a public GitHub URL (we read it on our server, then delete it — nothing is stored), or run private repos and local folders entirely in your browser or via the CLI, so the code never leaves your machine.
2. It reads the source. Explain My Build maps your routes, screens, data models, auth, environment variables and third-party connections directly from the files the AI wrote.
3. It writes three artifacts. A founder runbook, a ranked fix-list, and (optionally) an end-user guide — each claim cited to real code.
4. You review before publishing. A human — you — reads and edits the end-user guide before it goes live. Nothing is auto-published in your users' faces.

See how it works for the full mechanism, or try the live demo.

What are the three artifacts you get?

Explain My Build produces three distinct outputs from one code read. Two are free; one is paid.

The fix-list is ranked and code-verified, so you can hand it straight to Cursor, Claude Code or whichever AI you use and say "fix these." The end-user guide comes with a share link and access code, an in-app Help widget, and a portable export.

This is the wedge: developer-doc tools (Mintlify, Swimm, DeepWiki) emit docs for engineers; screen-recording tools (Scribe, Guidde, Supademo) build end-user guides from a human recording. Explain My Build is the one that writes an end-user guide from your code. See end-user guide vs developer docs.

Which tool built your app? Pick your guide

The method is shared, but each AI tool leaves a different fingerprint — different frameworks, different backends, different export behavior. These guides cover the specifics of documenting an app from each one:

• Document your Lovable app — React/Vite front end, Supabase or Lovable Cloud back end, GitHub sync.
• Document your Bolt (Bolt.new) app — in-browser WebContainer builds, Supabase, Netlify deploys.
• Document your v0 app — Vercel's React/Next.js + shadcn/ui generator.
• Document your Replit app — Replit Agent full-stack apps with managed hosting.
• Document your Cursor app — an AI IDE where you already have a real repo.
• Document your Windsurf app — the Cascade-agent IDE from Codeium, now owned by Cognition AI.
• Document your Base44 app — Wix-owned all-in-one builder.
• Document your Claude Code app — an app built agentically in your terminal.

Not sure your app is safe to ship? Start with a security read — for example is my Lovable app secure? or is my Bolt app secure?

What are the honest limits of this approach?

For the full boundary of what the tool will and won't claim, see limitations.