Services · Vibe Code Rescue

    It worked in the demo. It breaks in production.

    We audit and repair software built by prompting an AI rather than engineering it. First we tell you what is actually wrong and whether it is worth fixing. Then we fix it against criteria agreed in writing — and if we do not meet them, you do not pay for the fix.

    Editorial illustration: a small building presentable from the front while the other side stands open, showing exposed framing and loose wiring being braced and repaired

    Four ways these applications fail

    None of these show up in a demo. All of them show up once real people are using it.

    The fix spiral

    Asking the AI to fix one bug quietly breaks three other things, because nothing in the codebase is isolated and nothing has tests holding it in place. Each round of fixing makes the next round harder. Most people call us somewhere in the third or fourth round, when the app is further from working than it was a week ago.

    Secrets in the shipped code

    API keys, database credentials and tokens end up hardcoded in the bundle, in the repository, or in client-side code where anyone can read them. It usually works fine — right up until it is found, and finding it is no longer manual.

    Authentication that only looks right

    The login screen works, so the app feels secure. Underneath, endpoints accept requests without checking who is asking, and row-level rules are either absent or misconfigured. Nothing fails visibly, which is exactly the problem.

    The logic nobody wrote

    Payment webhooks that never retry, error paths that swallow failures silently, edge cases that were never considered because nobody asked for them. Under real traffic these do not throw errors; they just quietly lose orders, or money, or data.

    Two stages, and the second one is guaranteed

    01

    Audit and discovery

    You find out what is actually wrong, and whether it is worth fixing.

    We read the code, run it, and try to break it the way a stranger would. The output is a written report you own — including, where that is the answer, a recommendation not to spend money repairing this at all. The audit also produces the acceptance criteria the next stage is measured against, which is why it comes first and why it is a paid piece of work rather than a sales call.

    • Secrets and credentials audit — what is exposed in the shipped bundle, the repository and the client-side code
    • Authentication and access review — which endpoints can be called by someone who should not be able to
    • Architecture check — whether the data model and structure can carry where you are going, or need migrating
    • The failure inventory — what breaks, under what conditions, ranked by what it costs you
    • A prioritised roadmap with effort against each item, and the acceptance criteria for a fix

    Fixed scope, fixed fee, quoted on enquiry. You keep the report either way.

    02

    Fix and rectify

    The agreed criteria are met, or you do not pay for this stage.

    We work to the numbered criteria written during the audit — these bugs closed, these endpoints authenticated, these secrets rotated out of the bundle, this load sustained. Both sides agreed them before a line was changed, so whether they are met is checkable rather than arguable. Meet them and we invoice. Miss them and there is no fee for the fix.

    • The criteria closed out one by one, each demonstrable
    • Secrets moved out of the code and rotated, with the old ones treated as already compromised
    • Tests around the parts that broke, so the next change does not re-break them
    • A deploy path that can be repeated and rolled back
    • A handover your own people or your next developer can pick up

    Priced against the audit's criteria. Criteria met, we invoice. Criteria not met, no fee for this stage.

    Meet the criteria, or no fee for the fix

    The audit is a fixed-scope paid piece of work and you keep the report whatever you decide next. The fix stage is measured against the numbered criteria written into that report and agreed by both sides before any code changes. Meet them and we invoice. Miss them and you do not pay for the fix.

    Why exposed secrets stopped being a theoretical risk

    In September 2026 Anthropic published its threat intelligence report covering activity it disrupted between December 2025 and August 2026. One operation ran a credential-harvesting pipeline across ten cloud servers that mass-downloaded 1.8 million Android applications, decompiled them, and scanned them for hardcoded secrets automatically. A parallel stream collected stolen repository access tokens. Everything found was validated in batches — tested against live systems, graded for resale value — before use.

    That report is about attackers, not about how the software was written; it does not discuss AI-assisted development at all. The inference is ours, and it is simple. A hardcoded key used to be exposed only if somebody chose to look at your particular app. At 1.8 million applications scanned by machine, nobody is choosing. If the key is in the bundle, it is in the dragnet.

    Anthropic, Detecting and countering misuse of AI, September 2026

    When we tell you to rebuild instead

    Sometimes the honest answer from the audit is that repairing this costs more than starting again, and we will say so in the report rather than take the work. That is also why the guarantee sits on the fix and not the audit: we do not promise an outcome on a codebase we have already judged unsalvageable. If a rebuild is the right call we will quote it separately, and you are free to take the audit report to someone else.

    Vibe code rescue — common questions

    What is vibe code rescue?

    Auditing and repairing software that was built by prompting an AI rather than by engineering it. Typically the application works in a demo and fails in production — secrets exposed in the shipped code, endpoints that do not check who is calling them, payment and error paths that were never written, and a fix spiral where each AI-assisted repair breaks something else. We audit it, tell you whether it is worth repairing, and fix it against criteria agreed in writing first.

    What does it cost to fix a vibe-coded app in Malaysia?

    The audit is fixed-scope and fixed-fee, quoted on enquiry once we know roughly how large the application is and what it touches. The fix is priced against the criteria the audit produces, because until someone has read the code any number is a guess. We do not publish a price for either, and anyone who quotes you a fix before reading the code is guessing too.

    What if the fix does not work?

    Then you do not pay for it. The audit produces numbered acceptance criteria — these bugs closed, these endpoints authenticated, these secrets rotated out of the bundle, this load sustained — and both sides agree them before any code changes. Whether they are met is checkable rather than a matter of opinion. If they are not met, there is no fee for the fix stage. The audit is paid separately and is not covered by that, because the audit is where the criteria come from.

    Can you fix it if we built it ourselves with AI?

    That is most of this work, and there is nothing embarrassing about it. Building something that works by prompting an AI is a genuine achievement and it is how a lot of useful software now starts. What it does not give you is the part that keeps it standing under real users — tests, secrets handling, access control, a deploy you can roll back. That is the part we add.

    Will you tell us if it is not worth rescuing?

    Yes, in the report, and we would rather do that than take the money. If repairing it costs more than rebuilding it we will show you the comparison and quote a rebuild separately. You keep the audit report either way and you are free to take it to another developer.

    How do we avoid needing this again?

    Learn the part the AI does not do for you. Our Vibe Engineering courses cover exactly the gap this service exists to fill — tests as the contract for what working means, environments and secrets, reading a diff before you accept it, and a deploy pipeline from staging to production. Most clients who go through the rescue send someone on the course afterwards, which is the outcome we would prefer.

    Send us the repository, or just tell us what breaks

    A rough idea of the size of the application and what it touches is enough to quote the audit. You do not need to tidy anything first — we would rather see it as it is.

    Vibe Engineering courses · Fixing a broken AI agent · Software development