Finish a Claude Code app that will not launch.

With a coding agent, the files live in a repository on your machine and in your own account, so you start with more than many founders have at this stage. The trouble tends to show up later. The app runs when you start it on your laptop and you are unsure how to put it on the internet. A feature that worked last week has stopped and you cannot tell which session changed it. The agent says the work is done, and your only way to confirm that is to click around.

In the projects we see, four gaps account for most of this. Nobody has read the code as a whole. Nothing tests it automatically. Private keys sit in places they should not. The route from the repository to a live site is missing, or only the agent that set it up understands it. Each gap has a check you can do yourself. Find your symptom in the table and go to the section that covers it.

A coding agent can write in an afternoon what a person would need a week to read. When you accept each change because the app still starts, the repository fills with code that no person has looked at. Some of it is good. Some of it is a second version of a feature that already existed, a helper nothing calls, or a workaround for a problem that was later solved another way. The agent has to read through all of it on every task, and its changes get less reliable as the pile grows.

You can get a view of this without learning to program. Ask the agent to describe the project in plain language: what each top-level folder is for, which outside services the app talks to, and which parts it would not trust. Ask it for anything that appears to be unused or duplicated. Save the answers in a document inside the repository. Then slow the pace down: one task per session, a commit with a message you understand at the end of each, and a read of the summary of what changed before you accept it.

If you plan to keep building on the app for years, have a person read it once. A review by an engineer tells you which parts are sound and which will cost you later, and that judgment is hard to get from the same tool that wrote the code.

Your app holds keys to other services: the database, the payment account, email, perhaps an AI model. Each key should live in the settings of the place where the app runs and stay out of the code. In agent-built projects a key often ends up pasted into a source file to get something working, or a local settings file gets committed along with everything else. A key that was ever committed stays in the repository's history after you delete the line.

Ask the agent to search the code and the full commit history for anything that looks like a key or a password, and to list the files where it found them. Check whether the repository is public. Ask which keys are sent to the browser, because a visitor can read anything the browser receives. If a private key turns up in any of those places, replace it with a new one at the service that issued it and switch the old one off. Deleting the line leaves the old key working for anyone who already copied it.

The same care applies when you ask for help. Say where a key is stored and what it is for, and leave the value out. Never paste a password, a secret key or live payment credentials into a contact form, a chat window or an email, ours included. A person who needs access can be invited through the service's own sharing settings.

Carry on yourself while the checks above give you clear answers. If the agent can describe the project, the core journeys pass by hand, no private key is exposed and you can release and roll back, then what remains is ordinary building. Keep the sessions small and keep the list of journeys current.

Bring in an engineer when a key that guards customer data or money has been exposed, when the same fault returns after several repairs, when you cannot get the app deployed at all, or when you are about to take payments or store private records and nobody has reviewed the code. The Diagnostic is our fixed-price written plan for that situation. We read the repository, run the app, and write down what works, what blocks launch and what to do first, and the fee is credited to the build if you go ahead with us. We work in your repository under access you grant, so your repo and accounts stay yours.