Fix a Bolt app that will not get to launch.

Bolt writes a whole application from a conversation, and for a small project that conversation can hold everything. As the project grows, the tool has to work on part of it at a time. Late in a build that shows up in a few recognisable ways: a feature disappears after an unrelated request, an error comes back in a different file each time you ask for it to be fixed, or the app runs in the preview and refuses to publish.

None of these mean the work so far is wasted. In the Bolt projects we see, the product idea and most of the screens hold up, and the trouble comes from the project having grown larger than the way it is being edited. The table lists the stalls we see most, with a first check for each that needs no code reading.

Early on, each request to Bolt touches a few files and you can see the whole result on screen. Later, a request such as a new field on a form can lead the tool to regenerate a file that also contained your discount logic or your email step. The new version does what you just asked. Whether it still does what you asked three weeks ago depends on whether that older behaviour was visible to the tool when it rewrote the file.

You cannot see that from the chat, so keep a record outside it. Write a feature list in a plain document: one line per thing a customer can do, in words you could hand to a friend to test. After each change that touches more than wording or colour, walk the list. It is quick while the list is short, and it tells you on the day that something went missing, when the request that removed it is still the latest one.

Smaller requests also help. Ask for one behaviour at a time, name the screen it belongs to, and say what must stay as it is. A request that names its boundaries gives the tool less reason to rewrite code that already worked.

A browser-built app is quick to make partly because so much of it can run in the visitor's browser. Some work should never run there. Charging a card, sending email, calling an AI service on your account and anything else that uses a private key needs to happen on a server, because whatever the browser receives, a curious visitor can read. In the apps we see, a private key placed in browser code is one of the more common things to correct before launch.

You can look for this yourself. Make a list of every outside service the app talks to. For each one, find the key in that service's own dashboard and note its first six or eight characters. Then search the project files for those characters. If a key turns up in a file that builds the screens, ask where that code runs. A key the service describes as public or publishable is meant to be seen. A key described as secret is not, and if it has been in browser code on a published site, replace it with a new one in the service's dashboard once the code is corrected.

A missing feature you can trace to one request, a build error that changes each time you fix the top one, a key that needs moving: these are within reach if you work in small steps and keep copies. Many founders launch a Bolt project that way.

Ask for help when the same build error has survived several attempts, when features keep vanishing faster than you can restore them, or when the app takes payments or holds private data and you cannot say where the keys and the records live. At that point a person reading the whole codebase will usually see the cause faster than more requests will find it. Our Diagnostic is a fixed-price written plan. We read the project, list what blocks launch in the order to fix it, and credit the fee to the build if you go ahead with us. The code, the Bolt project and every connected account remain in your name.