I built an app with AI and don't understand the code — here's what to do

What you actually own after building an app with AI

Here's the reframe that matters: you own working software. A tool wrote the code, but the product — the thing people can sign up for and use — is real and it's yours. The gap you're feeling isn't a capability gap, it's a comprehension gap. Those are very different problems, and the second one is much easier to close.

The code your AI wrote is an asset. What's missing isn't more code — it's a map: a plain-English account of what your app does, how the pieces fit, and what's safe to touch. You don't need to be able to write that code from scratch to have that map. You just need something to read the code for you and explain it in words you understand.

And you're in good company. A whole generation of founders is shipping products built with Lovable, Bolt, v0, Replit, and Cursor — real apps with real users — that the founder couldn't rewrite by hand. That's not a dirty secret; it's the new normal. It's called vibe coding, and the honest move is to get a map of what you built, not to pretend you memorised it.

Three things you can generate from your code today

You can't un-build the app, and you don't need to. From the exact code you already have, three genuinely useful documents can be generated — each read straight out of your real files, not guessed:

• An end-user guide. Plain, task-by-task instructions for the people who use your app — "how do I reset my password", "how do I export my data". This is the one your customers actually need, and it's the one no screen-recording tool can write until your app is finished and you already know which flows matter.
• A founder runbook. A private operating manual for you: what each part does, how it's wired, and how to change one thing without breaking another — including the parts the AI wrote that you don't fully follow yet. This is the map.
• A code-verified fix-list. A ranked to-do of real improvements — each one checked against your actual code so you're not chasing false alarms — with a copy-paste prompt you can hand straight back to your AI. See what "code-verified" means.

The runbook and the fix-list are the free starting point. The user guide is the thing you eventually hand to customers.

How do I understand my app without reading the code?

You read the output, not the source. The workable method is to point a tool at your code, have it read every file, and translate what it finds into plain language — with each statement tied back to a specific file or route so you can trust it. That last part is the difference between a real map and a confident guess: a claim like "your app emails users a reset link" should point at the actual code that sends that email, not just sound plausible.

This is exactly the gap Explain My Build was built for. You paste your app's public GitHub link (or, for private or sensitive code, run it entirely in your browser so nothing leaves your machine), press one button, and it reads your code and its history and writes those three documents — citing real evidence and openly flagging anything it couldn't verify, so your review is a quick pass instead of a rewrite.

What to do first, in order

If you do nothing else, do these four steps in this order:

1. Get a map of what you built. Point a tool at your repo or your local folder and generate the founder runbook. Now you have a plain-English account of your own app.
2. Get the fix-list — and read the ones only you can do. Some improvements are setup jobs no AI can do for you (rotate a leaked key, turn on a security setting). Do those first.
3. Check it against your app. The draft flags what it couldn't verify. Click through your app with the runbook open and confirm it matches. This is where you catch anything off.
4. Add the user guide when you're ready to onboard people. Once real users show up, the end-user guide (and an in-app Help button) is what stops the same three support questions arriving every day.

When you should still bring in a developer

Honesty first: a plain-English map makes your app legible, it doesn't make you a security engineer. There are moments to bring in a human expert, and pretending otherwise would be the exact kind of over-claiming this tool is built to avoid:

• Money and sensitive data. If your app takes payments or stores health, financial, or personal data, get a developer or a security review before you scale — a documentation tool can flag likely issues from the code, but it is not a live penetration test.
• Something is actively broken or leaking. If you have reason to think credentials are exposed or data is at risk, treat it as urgent and get help.
• You're changing the core and it keeps breaking. A runbook lets you make small, safe edits; a structural rebuild is a job for someone who can read the code fluently.

For everything short of that — understanding your app, documenting it for users, and running it day to day — the map is enough. See what Explain My Build can and can't verify and who maintains your AI app when something breaks.