Fix an app you built with Cursor and cannot finish or deploy.

Cursor is an editor. It helps write and change code in a project that lives on your machine, which means you already hold something many founders using hosted builders have to go and fetch: the full source. It also means nothing was set up for you. Hosting, the live database, saved history and the settings a server needs are all yours to arrange, and an assistant that is good at the next change will not necessarily raise them.

So the stall tends to look different from a hosted builder's. The app works on your laptop and nowhere else. Each new feature takes longer than the last because the assistant has more code to get wrong. You have never deployed anything and do not know which of several hosting guides applies to you. Use the table to find where you are.

Over months of building, your computer collects things the project quietly relies on: a settings file that was never saved to the repository, a database that exists only on your disk, a tool installed once and forgotten. A server has none of them. The quickest way to find out what is missing is to pretend to be a new machine.

First confirm the code is in a remote repository and that the latest change there is recent. Then download a fresh copy into an empty folder, as a stranger would, and try to start the app using only the instructions in the project's README file. Ask the assistant to help, and tell it not to copy anything across from your original folder. Write down every extra thing you had to supply before it would run. That list is, in practice, your deployment checklist: every item on it is something the host will also need.

While you are on the repository website, search it for your settings file, which is often named with the word env. If it is there along with real passwords or keys, treat those keys as exposed, even in a private repository, and replace them in each service's dashboard after the file has been removed.

A test is a small program that checks one behaviour and reports pass or fail. Projects written quickly with an assistant commonly have none, or have some that were written and never run. Without them, the only evidence that a change was safe is that the screen you were looking at still works, and regressions in other screens surface days later.

Start with a manual version. Write the two or three journeys the business depends on as numbered steps, such as sign up, create the main thing, pay, and see it unlocked. Do them by hand after each working session. Once those steps are stable, ask the assistant to turn them into automated tests and to show you the command that runs them. Run that command yourself and watch it pass. Then break something on purpose, such as renaming a button, and confirm a test fails. A test suite that cannot fail tells you nothing, and assistants do sometimes produce one.

If the fresh-folder test turns up a short list and the host accepts the app once those items are supplied, you can very likely finish this yourself. The same goes for adding a handful of tests around the journeys that earn money.

It is worth paying for a second pair of eyes when the map of the project shows duplicated logic around money or permissions, when deployments fail for reasons that change each time, or when you are about to take payments and nobody but the assistant has reviewed how keys and customer records are handled. Our Diagnostic is a fixed-price written plan based on a read of your repository: what is sound, what blocks a launch, what to do in which order, and a quote for the next phase. The fee is credited to the build if you continue with us. The repository stays yours, and so do the hosting and service accounts we help you open.