Production Readiness Review

An independent review of your app before real users find the gaps.

Built with AI tools, by a freelancer or by your own team: before it takes payments, personal information or a tender, we review the code and the live deployment across twelve areas, from sign-in and data to monitoring and recovery. You get every finding ranked by severity, the evidence behind it, and a fix plan in priority order. We also tell you plainly what we could not check.

Request a review See a sample report

Twelve areas, one verdict

Each area is checked in the code and, where it shows, on the live site. Every finding names the file, the setting or the response it came from.

  1. Front end & performanceErrors in the browser, load speed on a phone, images, what users see when something fails.
  2. APIs & business logicInput validation, payment and webhook verification, error responses that leak nothing.
  3. Data & storageWho can read and write which records, injection risk, keys that must never reach the browser.
  4. Sign-in & permissionsSessions, password reset, roles checked on the server rather than hidden in the page.
  5. Security headers & secretsHTTPS, content security policy, clickjacking protection, secrets kept out of the code.
  6. Abuse controlsRate limits on sign-in, forms and checkout; protection from bots and credential stuffing.
  7. DependenciesPackages with known vulnerabilities, outdated frameworks, update automation.
  8. Testing & change controlAutomated tests and checks before a change goes live, and who can push to production.
  9. Hosting, staging & rollbackWhere it runs, a safe place to test, and how quickly a bad release is undone.
  10. Monitoring & error visibilityWhether anyone finds out when it breaks, and how fast.
  11. Backups & recoveryBackups that exist, restores that have been tested, a plan for a bad day.
  12. Privacy & POPIAWhat personal information is collected and why, consent, retention and a breach plan.

Sample report · illustrative

A booking and payments app, built with AI tools, two weeks from launch.

This sample is put together from findings that come up again and again in real reviews. It is not a client's report, and no client is named or described.

Verdict

Not ready for live payments. One critical and four high findings, all fixable without a rewrite.

The app works and the code is tidy. The gaps are in what AI tools tend to leave out: a database key exposed to the browser, payment notifications accepted without checking who sent them, and no limit on sign-in attempts.

03Data & storageCritical

Finding: the database's full-access key is included in the code sent to the browser. Anyone who opens the developer tools can read, change or delete every booking and customer record.

Evidence: the key appears in the built JavaScript bundle and in the client configuration file.

Fix: rotate the key today, move privileged queries to the server, and give the browser a restricted key with row-level access rules.

02APIs & business logicHigh

Finding: the payment provider's notification endpoint marks an order paid without verifying the notification's signature. A forged request can mark any order as paid.

Fix: verify the signature and the source on every notification, and confirm the amount against the order before updating it.

04Sign-in & permissionsHigh

Finding: admin screens are hidden from ordinary users in the browser, but two admin API routes do not check the user's role on the server. Any signed-in user can call them directly.

Fix: enforce the role on the server for every admin route, and add a test that calls each one as an ordinary user.

06Abuse controlsHigh

Finding: no rate limit on sign-in, sign-up or password reset. The sign-in form accepts unlimited guesses, which leaves accounts open to credential stuffing.

Fix: limit attempts per account and per address, and add a bot check on sign-up and password reset.

07DependenciesHigh

Finding: the web framework is pinned to a pre-release version with published high-severity advisories, and nothing alerts the team when a dependency becomes vulnerable.

Fix: move to the current stable release, and turn on automated dependency updates with an audit step that blocks high-severity issues.

05Security headers & secretsMedium

Finding: HTTPS is enforced, but there is no content security policy and no frame protection, so the site can be embedded and used for clickjacking. No secrets were found in the code or its history.

Fix: add frame protection now and a content security policy before launch.

08Testing & change controlMedium

Finding: no automated pipeline. Any change pushed to the main branch goes straight to production without tests, a build check or a dependency audit.

Fix: add a pipeline that runs tests, the audit and the build on every change, and require it to pass before merging.

10Monitoring & error visibilityMedium

Finding: errors are written to the console only. Nobody is alerted when checkout fails, and there is no uptime check.

Fix: connect an error-tracking service with alerts on payment and sign-in errors, and add an external uptime check.

11Backups & recoveryMedium

Finding: automated backups are not enabled on the database plan in use, and no restore has ever been tried. There is no written plan for an outage.

Fix: enable daily backups, run one restore into a test copy, and write a one-page runbook.

12Privacy & POPIAMedium

Finding: sign-up collects ID numbers with no stated purpose, and there is no record of consent and no breach plan. POPIA requires a lawful purpose and appropriate security for personal information.

Fix: stop collecting what is not needed, state the purpose at capture, record consent and write a breach procedure.

01Front end & performanceLow

Finding: no errors in the browser console, but full-size images make the main content take about 5.8 seconds to appear on a mid-range phone. A failed page shows a blank screen.

Fix: serve resized images and add a friendly error screen.

09Hosting, staging & rollbackLow

Finding: the host supports instant rollback, but there is no staging environment, so changes are first tested by real users.

Fix: use preview deployments with test payment keys for every change.

Fix plan

  1. Before launch Rotate and move the database key. Verify payment notifications. Enforce admin roles on the server.
  2. First week Rate limits and bot checks. Stable framework and dependency updates. An automated pipeline.
  3. First month Security headers, error tracking and uptime alerts, backups with a tested restore, the POPIA items, and image sizes.

What we could not check

  • Branch protection settings on the repository: no admin access was given.
  • Production environment values, such as whether secrets are long and random: held by the host, outside the code.

Every report lists these. A clean scorecard that hides what was not examined is worse than no report.

How a review runs

1 · Access

Read-only, nothing changed

  • Read-only access to the code repository
  • The live or staging address
  • No production data or passwords needed
  • Scope and timeline agreed in writing first
2 · Review

Code and live site, side by side

  • Architecture, sign-in, data and API code read in full
  • Dependencies checked against published advisories
  • Code and history scanned for leaked secrets
  • Live headers, responses and limits probed
3 · Report

A verdict you can act on

  • Plain-language verdict for the business owner
  • Scorecard across all twelve areas
  • Every finding with its evidence and fix
  • A walkthrough call with the engineers who did the review

Want the fixes done too? We can carry them out through digital rescue, then re-run the affected checks and update your scorecard. Once the fixes are in, a penetration test shows what an attacker could still do.

When a review pays for itself

Before launching an AI-built appFast to build, and quick to leave out the safeguards. Before buying or investingKnow what the software really is before the deal closes. Before a tender or enterprise clientAnswer their security questionnaire with evidence. Before handling personal informationPOPIA expects appropriate security from day one. After inheriting a systemFind out what you now own, and what it owes. Before you scaleFix the foundations while it is still cheap.

Questions

What is a production readiness review?

An independent check of whether an application is safe to put in front of real users, money and personal information. We review the code and the live deployment across twelve areas, rank every finding by severity, and give you a prioritised plan to fix what matters before launch.

Is this the same as a penetration test?

No. A penetration test attacks your system to prove what an attacker could do. A readiness review examines how it is built and run: sign-in, data handling, dependencies, deployment, monitoring and recovery. They complement each other, and many teams run the review first and the test once the fixes are in.

What access do you need?

Read-only access to the code repository and the address of the live or staging deployment. We do not need production data or passwords, and we never change anything during a review.

Our app was built with AI tools. Is that a problem?

Not in itself. AI tools produce working software quickly, but they rarely add rate limiting, server-side permission checks, backups or monitoring unless asked. Those are exactly the gaps this review is designed to find.

Will you fix what you find?

If you want us to. The report is yours to act on with any team. If we do the fixes, we re-run the affected checks afterwards and update the scorecard.

What does it cost?

A fixed quote after a short scoping call, based on the size of the codebase and how many environments are in scope. You know the price and the timeline before we start.

Find the gaps before your users do.

Tell us what the app does, what it was built with and when it goes live. We will come back with a scope, a fixed quote and a timeline.

Request a review Book a call