Mantyl.devGuides · handing over AI-built software

Before you hire someone to fix your AI-built app

The app you built with AI, or paid someone to build with AI, is misbehaving, and you are about to search for a developer to fix it. Reasonable move. Do one thing first, because it changes both the price you will be quoted and the odds the fix works: find out what is actually broken.

Why rescue work is priced the way it is

A developer quoting on a rescue project is quoting on the unknown. They have not seen the codebase, they do not know whether it even installs cleanly, and they have learned from experience that AI-built projects arrive with no reliable record of what works, what was tested, or what the previous builder actually did. So the quote prices in a discovery phase, uncertainty margin on top, and the strong possibility that the first billed week goes on simply getting the thing to run. That is how a bug that turns out to be one missing environment variable ends up inside a four-figure engagement.

None of that is dishonest. It is what quoting blind costs. Your job before hiring is to remove the blindness, and that turns out to be cheap.

Diagnose before you commission

The free Mantyl CLI runs an executed diagnosis of the project: it attempts install, build and tests in a clean, isolated sandbox, reads whatever AI-agent history exists alongside the repository, and produces a project passport recording what ran, what failed, what the agent claimed that the code does not support, and which required configuration is undocumented. If you built the app yourself, run it in the project folder. If someone built it for you, running it is a fair thing to ask of them, or of any technical friend, since it takes minutes:

npm install -g mantyl
mantyl scan && mantyl verify && mantyl generate
what runs, what fails by name, what was claimed, what is missing

This does not fix anything, and it does not judge the code. What it does is convert your problem is somewhere in here into a named list, on evidence a stranger can check.

What the result tells you to buy

If the verification shows the project cannot install or build cleanly, you likely have an environment and configuration problem before you have a code problem. These are often small, sometimes an afternoon, and you can now describe the failure precisely to whoever you hire instead of paying them to rediscover it.

If it runs but the passport shows contradicted claims and untested areas around exactly the features that misbehave, you have a scoping map: the gap between what was claimed and what was verified is where the fixing budget should aim.

If everything installs, builds and passes and the app still behaves wrongly, then the problem lives in logic or design that no automated check covers, and you genuinely need the human expert. You will hire them knowing that, which is worth real money, because you will not pay judgement rates for setup work.

Brief the rescuer with evidence

Whoever you hire, hand them the passport on day one. A developer starting with an evidence map of the codebase, its verified setup, its failure list and its decision history skips the archaeology phase entirely, quotes tighter, and starts on the actual problem. Several will tell you they would discount for it; all of them will work better because of it. When the fix is done, have them regenerate the passport, and this time the checks should pass. If the fixed delivery needs to convince anyone else, a Mantyl Verified run re-executes the checks on independent infrastructure and signs the result for a one-off £19 to £49, and a run that completes with failures includes a free re-run within 14 days, precisely so that verify, fix, re-verify costs one credit rather than two.

The honest boundary

Executed verification finds what fails to run, what contradicts the evidence and what nobody checked. It does not find subtle security holes or bad architecture; for software handling money or personal data, budget for a human review too, as covered in the vibe code audit guide. And if the rescue conversation is really a handover conversation, someone else is about to own this codebase, start with the AI code handover guide instead: it is the same evidence, pointed forward.

Use cases · Docs · PricingWritten against the real product