You built it with AI. Now you own it. Who maintains it?

Who is responsible for an app I built with AI?

You are. When you build an app with Lovable, Bolt, v0, Replit, Cursor, or Claude Code and put it in front of real users, you become its owner and its maintainer — often without realizing the job description changed the moment you shipped.

The AI tool wrote the code. It did not agree to keep the lights on. There is no support desk that knows your database, no engineer on call who remembers why a button does what it does. If a user hits a bug, if a payment fails, if the login stops working — that lands on you.

This is the quiet part nobody says out loud when they show you how fast you can ship. Shipping is the easy 20%. Owning what you shipped is the other 80%, and it starts the day your first real user shows up.

You do not need to become an engineer to handle it. You need to understand your own app well enough to make good decisions — what's safe to touch, what isn't, and when a problem is above your pay grade.

What actually breaks in AI-built apps?

The same handful of things, over and over. AI tools are good at generating features and less good at the boring plumbing that keeps them running. Here's where trouble usually lives:

• Environment variables and API keys. Your app talks to other services (a database, a payment processor, an email sender) using secret keys stored in environment variables. When a key expires, gets rotated, or was never set in production, features silently stop working. See API key.
• Database access rules. If you're on Supabase or similar, row-level security decides who can read whose data. AI tools sometimes leave this loose, which means one user can see another's records. This is the most common serious problem we see.
• Dependencies going stale. Your app is built on dozens of third-party packages. Over months they age, and old versions accumulate known problems — see technical debt.
• Changes that break other things. You ask the AI to "fix the checkout," and it quietly changes how signups work too. That's a regression — something that worked before and now doesn't.

None of these require deep coding knowledge to understand. They require a map. That's what the runbook gives you.

How do I change my AI-built app safely?

Move slowly and know what you're touching before you touch it. The fastest way to break an app you don't fully understand is to change code you can't see the edges of. A few habits that keep you out of trouble:

1. Read your runbook first. Before asking AI to change anything, know what the affected part actually does and what else depends on it. A founder runbook lays this out in plain language, cited to your real code.
2. Change one thing at a time. Small, single changes are easy to undo. Big sweeping ones hide their side effects.
3. Keep a working copy. Always have a version you can roll back to. If a change breaks something, you want a clean way back.
4. Test the paths that matter. After any change, walk through signup, login, and payment yourself. Those are the ones that cost you real money and real users when they fail.
5. Give your AI better instructions. A code-verified fix-list tells your AI exactly what to fix and where, instead of you guessing at prompts.

The goal isn't to never change your app. It's to change it with your eyes open.

How does the free founder runbook help me maintain it?

The founder runbook is a plain-English operating manual for your own app, generated by reading your actual source code — not a template, not a guess. It's free, and it's built for the person who has to keep the thing running.

Point Explain My Build at your app (paste a public GitHub URL, or run private repos and local folders entirely in your browser or via CLI so the code never leaves your machine). It reads the real code and produces three things:

• A founder runbook — how your app is wired, what each part does, how to operate and extend it. Free.
• A code-verified fix-list — a ranked list of real problems in your code, each cited to the line it came from, ready to hand to your AI. Free.
• A separate end-user guide for the people who use your app (this one is paid — see pricing).

Every claim in the runbook points back to a specific place in your code. When it can't verify something, it says so rather than making it up. That honesty is the whole point — see what it can and can't tell you.

See how it works or generate your runbook now.

When should I hire a developer instead?

Some jobs are worth handing to a professional, and pretending otherwise does you no favors. Consider hiring a developer when:

• Money, health, or legal data is involved and the stakes are real. If a mistake means leaking customer data or mischarging cards, get a qualified human to review before you ship.
• You've hit the same wall three times. If you and your AI keep circling a problem without solving it, a developer will often see it in minutes.
• You need something the tools genuinely can't do. Complex integrations, performance work under load, or anything requiring judgment about tradeoffs.
• You're scaling and can't afford downtime. Once real revenue depends on uptime, having someone who understands the system deeply is cheaper than the outage.