Turn AI-built software into a production-ready product

Our fixed-scope AI Code Audit starts from a published entry price for a single-product codebase, shown on the AI Code Audit page. That covers the automated pass, engineering review, classified findings register, prioritised remediation plan and a walkthrough. Larger systems, multi-repository estates, and engagements needing regulatory mapping are quoted individually after a scoping call. Remediation, security, architecture and readiness engagements are quoted against scope, because their effort varies by an order of magnitude depending on what the audit finds.

Usually fix it, but not always, and the decision should be made against evidence rather than frustration. A rebuild throws away working business logic and every undocumented lesson embedded in it, and it typically takes two to three times longer than estimated. It is genuinely the right call when the data model is fundamentally wrong for the product you now sell, or when the framework choice blocks something you have already promised customers. We apply a Retain / Refactor / Replace decision component by component, so the answer is rarely all of one thing.

Two weeks end to end for a typical single-product codebase, scoping on day zero, automated pass in the first two days, engineering review across the middle, classification and reporting in the final days. Larger or multi-repository systems are scoped individually and usually run three to four weeks. You do not wait until the end to hear anything: the findings register is shared as it develops, and anything Critical reaches you the day we find it rather than in a report a week later.

No. We need read-only repository access and, for infrastructure review, read-only cloud console access scoped to the relevant environments. We do not need production database access, customer data or credentials to live systems. Where an assessment touches data handling we review schema, classification and flow rather than records. An NDA is executed before scoping, access is granted to named reviewers only, and it is revoked on delivery. Where your policy requires it, analysis runs inside your own environment with only findings exported.

You should, and it will find real problems, outdated packages, committed secrets, known vulnerability patterns. Scanners are part of every assessment we run. What they cannot do is judge whether your authorisation model is coherent, whether your data model survives your next customer tier, or whether two modules disagree about who owns a record. Those findings require an engineer who understands what the system was supposed to do. The scan is the cheap half of the work, and it is the half that finds the less expensive problems.

Never without your instruction. The findings are yours. Many clients choose to share the report, a classified findings register with a dated remediation plan is a strong signal to an enterprise buyer or an investor, precisely because it shows the team knows where it stands. If you want a version written for that audience we will produce one. What we will not do is share anything with anyone, in any form, without your explicit written direction.

Then you get a short report saying so, and you spend the money on building instead. This happens more often than founders expect, particularly with products built carefully in a single framework by someone with prior engineering exposure. We would rather deliver that result and keep the relationship than manufacture concern. If a scoping call suggests the assessment is unlikely to earn its cost, we will say so before you commit rather than after.

Both, and they are separate purchases on purpose. The audit is a diagnosis and is deliberately available without any obligation to buy remediation from us, plenty of clients take the findings register to their own team or another supplier, which is a legitimate outcome. Where you do want us to execute, the Vibe Code Cleanup and Production Readiness & Hardening engagements pick up directly from the findings register, with the product staying live throughout.

Enterprise readiness is less about being flawless and more about being able to evidence your position. The practical test is whether you can answer, with documents rather than assurances: who can reach customer data and how is that enforced, how do you know a release did not break a control, what is your rollback path, and what happens when a dependency is disclosed as vulnerable. The AI Application Security Audit exists to produce exactly that evidence, mapped to the questions procurement teams actually ask.