Skip to content

Production Readiness Review

Find out whether your AI-built software is ready for real users

Our senior engineers review the code, validate it against the OWASP Application Security Verification Standard (ASVS), and give you an evidence pack with a prioritised plan. It is £5,500, fixed, and takes two weeks.

When to commission a readiness review

AI coding tools have made it possible to build a working application in weeks. In our experience, the gap is rarely whether the app works. The gap is whether anyone has checked how it handles secrets, permissions, dependencies and accessibility before people depend on it.

Before real customers use it

Your app was built quickly with AI tools and it works. Before customers, staff or partners rely on it, you want to know what has to change and in what order.

When a buyer asks for security evidence

A customer, procurement team or investor has sent a security questionnaire. You need a dated, written record of what was checked, rather than an assurance that it is fine.

Before we support AI-generated code we did not build

For an AI-generated codebase we did not build, the review is the required first step before ongoing managed support. It tells us both what we would be taking on.

When your own team builds with AI

Your developers, analysts or operations team now produce software with AI coding tools. You want an independent check from engineers who did not write the code.

What the review covers

The same six areas on every review, whoever built the software and whichever tools they used.

Static code analysis

GitHub Advanced Security, extended with our own in-house rules, scans the whole codebase for defects, insecure patterns and exposed secrets.

Secure coding validation

Senior engineers check the code against the OWASP Application Security Verification Standard (ASVS) and our own suite of checks, built from the findings of penetration tests on previous projects.

Dependency audit

Every third-party package, checked for known vulnerabilities, unmaintained projects and versions that are falling out of support.

Accessibility scan

Automated accessibility testing against the Web Content Accessibility Guidelines (WCAG) 2.2 AA, plus standard techniques and tools.

Test coverage baseline

What the tests verify today, as opposed to what they appear to verify, and where the gaps are on the parts of the system that matter most.

A prioritised plan

Every finding ranked by severity, with the fix it needs, so you can see what must change before launch and what can wait.

Validated against OWASP ASVS

The OWASP ASVS is an open standard from the Open Worldwide Application Security Project. It sets out what to verify in an application's security, in three levels of increasing depth. We choose the level with you at the scoping call:

  • Level 2 is our default for business-critical systems, including anything that handles personal data.
  • Level 1 suits early-stage prototypes that are not yet in front of customers.
  • Level 3 is available on request for the highest-risk systems.

Full verification at any level includes configuration and architecture requirements that code review cannot reach on its own. We validate against the requirements that apply to the code, and the report lists which ones we checked and which were out of scope. We never describe a system as 'ASVS compliant' or as certified.

Senior engineers carry out the validation. On code we built ourselves, the reviewer is never the person who wrote the change. Our secure coding suite adds checks drawn from the findings of penetration tests on our previous projects, so lessons from real tests feed every review.

Our production readiness checklist for AI-built apps sets out the items we check, mapped to ASVS and Cyber Essentials Plus, so you can see what is covered before you book.

An evidence pack, not a certificate

At the end of the review you receive a dated evidence pack. It records:

  • What we checked, against which ASVS requirements, and what was out of scope
  • The results of the static analysis, dependency audit, accessibility scan and test coverage baseline
  • Every finding, ranked by severity, with the fix it needs
  • A prioritised plan showing what must change before launch and what can wait

You can share it with customers, procurement teams and investors who ask how the software was checked. It describes what was checked and what was found. It does not certify the system or guarantee its security, because no review can do that.

An example of a two-week Production Readiness Review: each finding comes with a planned fix, and the costed plan shows what it takes to make the system safely supportable. Illustrative data for a fictional client.

How the two weeks run

From the scoping call to an evidence pack and a plan you can act on.

The stages of a production readiness review, from scoping to static analysis, ASVS validation and an evidence pack
The seven stages of a two-week production readiness review. First, scope: agree the system, the ASVS level and read-only access at a scoping call. Second, static analysis, where GitHub Advanced Security and our in-house rules scan the codebase automatically. Third, highlighted, secure coding validation by senior engineers against OWASP ASVS and our suite built from previous penetration test findings. Fourth, a dependency audit for known vulnerabilities and unmaintained packages. Fifth, an automated accessibility scan against WCAG 2.2 AA. Sixth, a test coverage baseline showing what the tests verify today and where the gaps are. The findings are then ranked by severity. Seventh, the evidence pack and plan: what was checked, what was found, and what to fix first.

Three steps, one fixed price

The review has a fixed scope, so you know the cost and the timing before it starts.

  1. Scoping call

    30 minutes

    We agree what the system does, who uses it, and which ASVS level fits it. We also agree read-only access to the repository and, where possible, to the hosting and deployment setup.

  2. The review

    Two weeks

    Automated analysis and expert review run side by side. GitHub Advanced Security and our in-house rules scan the codebase, while senior engineers validate the code against the agreed ASVS requirements and our own suite of checks. The same fortnight covers:

    • A dependency audit
    • An automated WCAG 2.2 AA accessibility scan
    • A test coverage baseline
  3. Evidence pack and plan

    You receive the evidence pack and the prioritised plan. The findings and the plan are yours whether or not you go on to work with us.

From findings to fixes

The review has a fixed scope, so fixing what it finds is a separate decision. You have three options:

  • Your own team works from the plan.
  • We fix the findings as a separately quoted piece of work.
  • The fixes become tickets under ongoing managed support for AI-built software, which starts from £2,450 per month.

For an AI-generated codebase we did not build, this review is the required first step before ongoing support, and it replaces what we previously called the Stabilisation Assessment. If your app is already failing in production, our vibe coding rescue service stabilises it first. If you are still taking a prototype towards launch, our prototype to production service covers the build.

We hold ISO 27001 and Cyber Essentials Plus certification ourselves. Our guide to keeping supported software secure explains how we handle vulnerabilities once a system is in support.

Seen enough? Let's talk through your requirements.

Book a free consultation

Frequently asked questions

What is a production readiness review?

It is a fixed-fee, two-week review that tells you whether an application is ready for real users, and what has to change if it is not. It combines static code analysis, expert-led secure coding validation against the OWASP Application Security Verification Standard (ASVS), a dependency audit, an accessibility scan and a test coverage baseline. You receive the results as an evidence pack with a prioritised plan.

How much does it cost, and how long does it take?

£5,500, fixed, over two weeks. The price does not change with what we find. Fixes are separate, so the review stays a fixed piece of work you can budget for.

Which OWASP ASVS level do you validate against?

Level 2 by default for business-critical systems, Level 1 for early-stage prototypes, and Level 3 on request for the highest-risk systems. Full verification at any level includes configuration and architecture requirements that code review cannot reach on its own. Every report therefore lists which requirements we checked and which were out of scope.

Is a production readiness review the same as a penetration test?

No. A penetration test is an authorised, simulated attack on a running system at one point in time. Our review works from the code: static analysis, secure coding validation, dependencies, accessibility and tests. Our secure coding suite is built from the findings of penetration tests on previous projects, so issues that real tests have found are checked for on every review. If a customer or insurer needs a penetration test, commission it from a CREST-accredited tester, and we can fix its findings alongside ours.

Can you review an app built with Lovable, Bolt, Replit or Cursor?

Yes. We review code we did not build as well as our own, whichever tools produced it. AI app builders and coding assistants tend to leave similar gaps, such as secrets in the code, missing authorisation checks and tests that assert very little. The review is designed to find them. If your app is already failing in production, start with vibe coding rescue instead.

How is it different from a maintainability review?

A maintainability review answers a due diligence question: what is this software worth, and what would it cost to keep? It suits acquisitions, investments and agency exits, and is scoped and priced for each engagement. A production readiness review answers a launch question: is this safe to put in front of users, and what evidence can we show? It has a fixed scope and a fixed price.

Can you fix what you find?

Yes. Fixes run either as tickets under managed support or as a separately quoted piece of work. Your own team can also work from the plan. The engineers who found the issues are the same team that can fix them.

Does the review include load testing?

No. The review works from the code and does not run the system under load. We carry out load, stress and soak testing with Azure Load Testing as part of our delivery and managed support work. We use it to find and fix scalability problems, design scaling strategies such as Kubernetes autoscaling, and size infrastructure for performance and cost.

See how AI is changing how we build software

Our quarterly AI Velocity Report tracks real delivery metrics from live projects: how much of our code is AI-authored, how delivery timelines compare to baseline, and which tools are making a measurable difference. No marketing spin, just honest data from a team that builds software every day.

Read the latest AI Velocity Report

Know what has to change before your users find it

Book a consultation to scope a production readiness review. You get the evidence pack and the plan whether or not you go on to work with us.

Book a consultation

or call 01202 006729