Your vibe-coded app works in the demo. Audit it before you rebuild.

There are three options. Finish means the base is sound and you keep building on it. Fix means parts are sound and named parts get repaired or replaced. Rebuild means repair would cost more than a clean start, and you carry over what you learned and, with some care, the data.

You can't tell which one you're in from the demo. A demo shows one path, on one day, with one user. It says nothing about who owns the accounts or whether a second developer could even get the thing running.

So the audit runs in a fixed order, and the order matters. Each check decides whether the next one is worth doing. If you don't control the repository, there's no point reading the tests yet.

A made-up example to keep in mind: a founder has a booking app for a yoga studio. The demo books a class. The audit finds that the code sits in the freelancer's personal account and the payment key is saved in a file that anyone with the code can read. Neither shows up in a demo. Both have to be dealt with before a single feature gets added.

The prompts below are written for Claude Code, Anthropic's coding agent. You open it inside the project folder and type in plain language. Another coding agent that can read a folder will do too.

Two things keep it from changing anything. In its default mode, Claude Code stops and asks before most actions that edit files, run commands or reach the network, and you can say no. Plan mode is stricter: the agent reads and explores, then writes up what it found, and it doesn't edit your files. In the terminal you switch modes with Shift+Tab. The desktop app has a mode selector. Use plan mode for the whole audit.

Work on your own copy of the code. Ask for read access to the repository and download it to your laptop. A copy on your laptop has no connection to the live app, unless the code itself carries live keys, which is one of the things check 5 looks for.

Know the limits too. The agent sees files. It doesn't see your hosting dashboard, your domain registrar, or who the admin of the code account is. Those you check by logging in, and each prompt tells you what to look up. One more thing: whatever the agent reads is sent to the model provider for processing. If a contract you've signed forbids that, clear it before you start.

What to look for: every account your product lives in should belong to your company, with the developer invited in. That covers the code host, the hosting and the database, the domain, the app store accounts if there's a mobile app, and the services the app pays for, such as payments, email and AI models. I wrote a separate post on putting those in your company's name.

The agent can't log in to any of that. What it can do is read the code and list every outside service the app talks to. That gives you the list of accounts to check, and it's easy to miss one from memory.

Then comes the part only you can do. For each row, log in yourself. Can you? Are you the owner, or a guest? Whose card pays the bill? If the honest answer is "I'd have to ask the developer", write that down as a finding.

If ownership turns out to be unclear, stop here and sort it out before you go on. An estimate for an app you can't get into is a guess.

Paste the prompt below. In its answer and in your own logins, these are the red flags:

• The repository sits under a person's username and not in a company organisation you own.
• Hosting, database or domain is registered to the developer's or the agency's email address.
• One person holds every password, and there's no list of who has access to what.
• Nobody can say how you'd remove a developer tomorrow and keep the app running.

Goal: List every outside account and service this app depends on, so that I can check who owns each one.
Inputs: This repository: the git remote address, configuration and deployment files, example environment files, package lists, the README and the docs.
Constraints: Read only. Do not edit, create or delete files. Do not install anything and do not run the app. Never print the value of a key, token or password. Name the file and the variable only. If you cannot tell something from the repository, say so and do not guess.
Definition of done: A table with one row per service (code host, hosting, database, domain and DNS, email, payments, maps, AI models, analytics, app stores). For each row: the file and line where you found it, any account or organisation name that appears, and an empty column called "owner confirmed by login" that I will fill in myself.

The README is the instruction file at the top of the repository. In a healthy project, a developer who has never seen the code can follow it on a new computer and have the app running locally, without messaging the person who wrote it.

Why you care: every hour a new developer spends guessing at the setup is an hour you pay for, and you pay it again with each new person. An app that only runs on its author's laptop is also an app nobody else can safely change.

The prompt gives you a paper check. It compares the README with the files and runs nothing. The real test is a person: ask any developer who quotes you to follow the README on a fresh machine and tell you how long it took and where they got stuck. I'd trust that report more than their opinion of the code.

Red flags:

• No README, or one that is still the template the framework generated.
• Steps that mention files, commands or folders that don't exist.
• No example settings file, so nobody knows which keys the app needs.
• "Ask me for the file" as a setup step.

Goal: Tell me whether a new developer could set up and run this app from the README alone.
Inputs: The README, setup docs, example environment files, package and lock files, and any scripts the docs mention.
Constraints: Read only. Do not install, build or run anything. Do not edit files. Walk through the README step by step as if you were on a new computer, and check each step against the files that exist. Never print secret values.
Definition of done: Every setup step marked as "documented and matches the files", "documented but wrong" or "missing". A list of every setting the app needs and whether the README says where to get it. Then a yes or no answer with reasons, in words a non-engineer can follow.

The repository is supposed to be the one record of what your product is, and the live app is supposed to be built from it. Two things break that. Somebody patches the live server by hand and never saves the change back. Or work piles up in the repository that never ships. Either way, what you test and what your customers use are different things.

The agent can read from the files how code gets to the live site, and it can tell you what the latest version in the repository is. Which version is actually live, you look up yourself. Many hosting dashboards list each deployment together with the version of the code it came from. If yours does, compare it with what the agent reports. If the host can't tell you what is running, or deploying means someone uploads files by hand, that is your finding.

Another made-up example: the live site shows a price of 29 euros and the code in the repository says 25. Someone changed the live version by hand. Until the two match again, you can't trust what you read in the repository, and an estimate based on it won't hold.

Red flags:

• Nobody can name the version that is live.
• Fixes made straight on the server, with no record in the repository.
• Database changes typed in by hand, with no file that records them.
• Deployment that only works from one person's laptop.

Goal: Explain how this app gets from the repository to the live site, and tell me what to compare to find out whether live and repository match.
Inputs: Deployment configuration and scripts, automation files, the deploy section of the README, and the git history and branches. For git, only read the log and the status.
Constraints: Read only. Do not deploy, push, pull or switch branches. Do not connect to any live system. Do not run database changes. Use plain words.
Definition of done: The deploy path as numbered steps, including who or what triggers it and from which branch. The date and short id of the latest commit on that branch. Any uncommitted changes, and any branches that are ahead of it. A list of database change files and how they get applied. And the exact thing I should look up in the hosting dashboard to see which version is live.

A test is a small program that uses the app the way a customer would and complains when something stops working. Tests are how a developer changes one thing without quietly breaking another. Don't assume an AI-built app has any. And if it has a lot, don't be impressed by the number. What counts is which flows they cover.

You don't need hundreds. You need tests on the few flows the business depends on: someone can sign up, sign in, do the main thing the app is for, and pay if payment is part of it. They should also run automatically on every change, not when somebody remembers.

Made-up example: the sign-up form has no test. A developer renames a field, sign-up fails silently, and you find out days later because the new-customer emails stopped. A test on that flow would have failed before the change went live.

Docs do the same job for people: how to set the app up, how to ship and roll back, where the keys live. Red flags:

• No tests at all, or tests that fail and have been failing for a while.
• Tests exist, but nothing runs them automatically.
• No note on how to roll back a bad release.

Goal: Map which automated tests and which docs exist, and which core flows they protect.
Inputs: Test folders, test configuration, automation files, the docs folder and the README.
Constraints: Read only. Do not write or change tests. Do not run the tests. I will ask a developer to do that. Name each gap plainly.
Definition of done: A list of the existing tests and what each one covers, in plain words. The core flows (sign up, sign in, the main task, payment) each marked as covered, partly covered or not covered. Whether the tests run automatically on every change. Which docs exist and which are missing (setup, deploy, rollback, keys and settings). Anything in the docs that contradicts the code.

Secrets in code. Keys and passwords belong in the hosting provider's settings, not in files. If a key was ever saved in the repository, deleting the line doesn't help, because the repository keeps every old version. The key has to be replaced with a new one at the provider. That's called rotating it.

Outdated packages. Every app is built on shared building blocks written by other people, and old versions have known holes. The agent can list what the app uses. It may also ask to run the package manager's audit command, which looks up known problems and only reports them. You can allow that. Say no to any command with "fix" in it. That's for a developer to do on purpose.

Open admin pages. Any screen where someone can see all customers or change prices has to check, on the server, that the visitor is allowed in.

Auth that only hides buttons. This is the one I'd look at hardest. The page hides the delete button from normal users, but the server would still carry out the delete if someone sent the request directly. The check has to live on the server, for every action.

Personal data in logs. Names, email addresses or login tokens written to log files that more people can read than should.

Treat a live key in the code as urgent. Have it rotated today, then carry on with the audit. Red flags:

• A key, token or password in any file in the repository or in its history.
• An admin page for which the agent can't find a server-side check.
• Any action whose only protection is in the browser.
• Packages several major versions behind, and nobody responsible for updates.

Goal: Find the common safety gaps in this code and explain each one in plain words.
Inputs: All source files, configuration, example environment files, package and lock files, route and middleware files, and the git history of any file that looks like it once held secrets.
Constraints: Read only. Do not edit anything. Do not open or call the live site. Never print a full secret. Show the file, the line and the first four characters only. Explain each technical term once. Give the file and line for every finding.
Definition of done: Five lists, most urgent first. 1: keys, passwords or tokens written in code or in committed settings files, now or earlier in the history. 2: packages that look far behind or unmaintained, marked "to confirm with an audit tool". 3: every admin or internal page and route, and where the server checks who is asking. 4: actions where the check happens only in the browser. 5: personal data written to logs.

Now you can ask for prices. Most founders skip to this step, ask one developer what a rebuild would cost, and get a number with nothing to compare it to. Ask each developer for two estimates, one to finish and one to restart, in the same format. Hand them your findings from checks 1 to 5 first. The last prompt turns those findings into a one-page brief with blanks for the numbers, so every bidder prices the same thing. Don't let the agent fill in prices itself.

Each estimate should say what stays, what gets repaired, what gets replaced and what is out of scope. It should list the work in order: ownership, setup, getting live and repository to match, security, tests on the core flows, and only then features. And it should name what the developer doesn't know yet.

Both options hide costs, in different places. Check that a rebuild quote has lines for moving existing customer data, replacing keys, switching the domain over and telling users. Check that a finish quote has lines for repairing setup and docs, lining up live with the repository, and the security findings. If a line is missing, ask where it went.

On how to pay: a fixed price per step suits work that can be described, such as "add tests for sign-up and payment". Hourly billing with a cap suits investigation, where nobody knows yet what they'll find. I go into that in what fits in a first MVP and what it costs in Germany.

How I'd read the result: if you own everything, the app builds from the README, live matches the repository and the security findings are few and specific, finishing is probably the cheaper road. If ownership is tangled, nobody can build it and the access checks live in the browser, a restart may well cost less than the repairs. If yours lands in between, that's what "fix" is for. And if you'd like me to look at the two estimates with you, send them over with the findings attached.

Red flags in an estimate:

• Only one option is priced.
• No out-of-scope list and no named unknowns.
• A fixed price for work nobody has investigated yet.
• Hourly billing with no cap and no checkpoints.
• No line for data migration, key rotation, tests or docs.
• Pressure to sign this week.

Goal: Turn my audit findings into a one-page brief that I can send to developers, asking each for two estimates: one to finish this app and one to restart it.
Inputs: The findings from the five checks, which I paste below: [paste findings]. What the app must do for its first real customers: [describe in two or three sentences].
Constraints: Read only. Do not change any file. Do not invent prices, hours or dates. Leave a blank wherever a developer has to quote. Use plain words that a founder can forward as they are.
Definition of done: One page with a summary of the findings, then two identical tables, "Finish" and "Restart". Each table has rows for ownership, setup and docs, matching live and repository, security, tests, data migration, key rotation and features, with blank columns for scope, price, fixed or hourly, and unknowns. Below the tables, an out-of-scope list and the questions I need to answer before anyone can quote.