Explain My BuildThe plain-English glossary for founders who built an app with AI
Last updated: July 26, 2026
This glossary defines the words you'll meet after building an app with an AI tool like Lovable, Bolt or Cursor: end-user guide, founder runbook, code-verified fix-list, technical debt, README and more. Each entry answers in one line, then links to a fuller definition written for a non-technical founder.
What is this glossary for?
This glossary explains, in plain English, the terms you run into once you've built a real app with an AI coding tool but can't read the code it wrote. It's written for the non-technical or semi-technical founder, not for engineers.
You built something with Lovable, Bolt, v0, Replit, Cursor, Claude Code, Windsurf, Base44 or Gemini. It works. Now people ask how to use it, a developer asks how it's built, or a tool warns you about "technical debt" and you're not sure what any of it means. Start here.
The words most likely to trip you up: the difference between an end-user guide and developer docs, what a founder runbook is, and why a README is not something your customers should ever read.
If the code itself is the thing you don't understand, start with the pillar: I built an app with AI and don't understand the code.
Core Explain My Build concepts
These four terms describe the artifacts Explain My Build produces from reading your actual source code.
| Term | One-line answer |
|---|---|
| End-user guide | Step-by-step instructions for the people who use your app, written from your code, not from a screen recording. |
| Founder runbook | A plain-English manual for you to operate and extend the app you built: how it's wired, what to check, what to hand a developer. |
| Code-verified fix-list | A ranked list of real issues found in your code, each cited to the exact file so nothing is guessed or hallucinated. |
| In-app Help widget | An embeddable Help button that shows your end-user guide inside your app, so users get answers without leaving. |
The runbook and fix-list are free. The end-user guide plus sharing (share link and access code, the Help widget, and a portable export) is $19/month, or $12/month founding for the first 100 users. Cancel anytime. See pricing.
Vibe-coding vocabulary
These terms describe the way AI-built apps get made and the debt they can quietly carry.
| Term | One-line answer |
|---|---|
| Vibe coding | Building software by prompting an AI in natural language and iterating, rather than writing code by hand. |
| MVP | Minimum viable product: the smallest version that lets you learn whether people want it. |
| Technical debt | Shortcuts in the code that speed you up now but cost you later; AI tools accrue it invisibly. |
| Regression | Something that used to work and now doesn't, usually after a change. |
Security terms you'll hear
If a scan or a developer flags something, these are the words most likely to come up. Each links to a fuller definition.
| Term | One-line answer |
|---|---|
| API key | A secret password your app uses to talk to another service; it should never be visible in your front-end. |
| Environment variable | A setting (often a secret) kept outside your code so it isn't exposed. |
| Row-level security | A database rule that stops one user from reading another user's data. |
| Supabase | A common back-end for AI-built apps that stores your data and handles logins. |
| Software bill of materials | A list of every third-party package your app depends on. |
| Supply-chain attack | When an attacker compromises one of those third-party packages instead of your app directly. |
Honest note: Explain My Build reads your code and flags likely issues. It is not a live penetration test. See limitations.
Docs and handoff terms
These describe the documents and the moment you bring in help.
| Term | One-line answer |
|---|---|
| README | A short file at the top of a codebase for developers; not a guide for your users. |
| Developer docs | Documentation written for engineers who work on the code, not for the people who use the app. |
| Handoff to a developer | Giving a developer everything they need to take over: the runbook is most of this. |
Ready to turn your code into these documents? Try the free runbook and fix-list first: see how it works or run it on your repo.
Frequently asked questions
What is the difference between an end-user guide and developer docs?
An end-user guide is for the people who use your app; it tells them how to sign up, do the main tasks, and fix common snags. Developer docs are for engineers who work on the code. They're written for different readers and shouldn't be swapped.
I built an app with AI and don't know these words. Where do I start?
Start with vibe coding and MVP to name what you've done, then read end-user guide and founder runbook to understand what documents you need next. The pillar page I built an app with AI and don't understand the code ties it together.
Is a README the same as an end-user guide?
No. A README is a short file for developers at the top of a codebase. An end-user guide is written for your customers. If you hand a customer your README, they won't know what to do with it.
Turn your app into a guide your users can follow.
Paste a public GitHub link and get your founder runbook + fix-list free in about a minute — no sign-up. Private code runs entirely in your browser.