Production Readiness Review
In five days, we will tell you whether your software is ready to go live.
You have built something with AI and it works. Before real customers, real data or real traffic arrive, one of us will check it properly and tell you what needs fixing first.
- Price
- From £1,500
- Turnaround
- 5 working days
- You get
- A short report, a red, amber and green summary, and the top ten fixes
- Then
- A fixed quote to fix them, if you want one
That is a fixed price for one application or plugin on one hosting environment. If yours is larger, we will quote before we start, and the price will not change once agreed.
Who it's for
It is for anyone putting code that an AI wrote in front of real users.
It might be a WordPress plugin from Claude Code, an internal tool from ChatGPT, a customer portal from Lovable or Cursor, or a Power Automate flow that has somehow ended up touching payroll.
If it handles real data, real money or real customers, someone experienced should look at it before it goes live, or soon after if it already has. That is usually far cheaper than dealing with the first incident. Keep using AI. Just don't deploy it unchecked.
What we check
We check five areas, all of which a quick test by hand tends to miss.
Security and personal data
- Who can reach each page, endpoint and admin action, and whether anything actually checks
- What personal data is stored, where, for how long and who can read it (in other words, your GDPR exposure)
- Passwords, API keys and secrets left lying about in code or config
- Escaping, input handling and the classic injection mistakes
Performance and server load
- Database queries per page, and queries inside loops
- What your busiest page does with ten times the visitors
- Caching, background jobs, and anything that holds a page up while it waits
Hosting cost
- What it costs to run today, and what it will cost at the size you are planning
- Paid API calls (AI calls included) that grow with every user
- Whether your hosting plan fits, or is far bigger than you need
Maintainability
- Whether anyone other than the original AI conversation could change it safely
- Version control, dependencies, updates and known vulnerabilities
- Backups, and whether anyone has ever tried restoring one
Behaviour at scale
- Two people doing the same thing at the same moment
- Large inputs, slow third parties, and failures halfway through
- What you will see, and who gets told, when something breaks
"Working" is not the same as "safe".
Everything above can be wrong in software that passes every test you try by hand. That is no failing on the part of whoever built it; a quick test simply does not look there.
Illustrative example. A made-up report, not client data.
Production Readiness Review
Event booking plugin (WordPress)
| Area | Rating | What we found |
|---|---|---|
| Security | Red | The export endpoint checks that a request came from the site but not who sent it. Any logged-in subscriber can download every booking. |
| Personal data | Red | Names, emails and phone numbers are kept forever in a custom table, with no way to delete one person on request. |
| Performance and server load | Amber | The events page runs one database query per attendee. That is 40 queries today, and around 400 at the size you are planning. |
| Hosting cost | Amber | This is fine on current traffic, but the planned campaign would need a larger hosting plan unless the query problem is fixed first. |
| Maintainability | Amber | Everything is in one 1,900-line file with no version control (no record of what changed, or when). It can be read, but realistically only by asking the AI that wrote it. |
| Behaviour at scale | Green | Bookings are written safely when two people book the last place at the same moment. |
Top ten fixes (first 5 shown)
- Check the user's role on the export endpoint, not just the request token. (Half a day.)
- Add a retention rule and a "delete this person" action for booking data. (One day.)
- Load attendees in one query instead of one per row. (Two hours.)
- Escape attendee names before printing them on the admin screen.
- Move the payment provider key out of the plugin file and into the server environment.
What you get
The report is written so that you can act on it the same day.
The first page gives you the answer: each area rated red, amber or green, with a sentence explaining why. After that come the ten fixes that matter most, in order, each with a rough idea of the effort involved.
Behind that is the detail your developer, agency or AI assistant will need to make each fix: the file, the line, what to change and how to check that it worked.
- Red means fix it before go-live (or now, if it is already live).
- Amber means fix it soon, or before you grow.
- Green means we checked and it is fine.
What a finding looks like
These eighteen lines work, and still have four problems hiding in them.
AI assistants write code like this all the time, because it is the most common way to write it, and it will pass every test you would think to try.
Illustrative example. Typical AI-written code, not client code.
// [event_attendees id="12"] lists who is comingfunction eb_attendees( $atts ) { global $wpdb; $table = $wpdb->prefix . 'eb_bookings'; $rows = $wpdb->get_results(Problem 1 "SELECT * FROM $table WHERE event_id = {$atts['id']}" ); $html = '<ul class="attendees">'; foreach ( $rows as $row ) {Problem 2 $person = $wpdb->get_row( "SELECT * FROM {$wpdb->prefix}eb_people WHERE id = $row->person_id" );Problem 3 $html .= '<li>' . $person->nameProblem 4 . ' (' . $person->email . ')</li>'; } return $html . '</ul>';} -
Input pasted into SQL
The id goes straight into the database query. Using
$wpdb->prepare()means a specially crafted value cannot change what the query does. -
A query inside a loop
The code runs one extra database query for every attendee, so 40 attendees means 41 queries on every page view. Fetching them all in a single query (with a JOIN) fixes it.
-
Unescaped output
Names are printed as raw HTML, so anyone who books with a script tag as their name can run code in every visitor's browser. Wrapping the name in
esc_html()prevents that. -
Personal data on a public page
Email addresses are shown to anyone who can see the page, including search engines, which makes this a data protection problem before it is anything else.
What fixing it looks like
Here is the same page on the same server, before and after two fixes.
Query problems are invisible with ten visitors and painful with two hundred, and the day you get two hundred tends to be the day of your campaign, your launch or your newsletter.
Fixing the query loop and adding a page cache took a morning, and it meant the planned move to a bigger hosting plan was no longer needed.
Illustrative example. Not client data.
Page time as visitors increase
Slowest 5% of page loads, in seconds, against visitors on the site at once
As built, the page slows right down beyond about 75 visitors, because every view runs dozens of database queries. Once the attendees are loaded in one query and the page is cached, it stays under half a second at 200 visitors on the same server.
Show the numbers
| Visitors at once | As built | After fixes |
|---|---|---|
| 10 | 400 ms | 250 ms |
| 25 | 600 ms | 260 ms |
| 50 | 1.1 s | 270 ms |
| 75 | 1.8 s | 290 ms |
| 100 | 2.6 s | 310 ms |
| 150 | 5.4 s | 360 ms |
| 200 | 9.6 s | 420 ms |
How the five days work
The review takes one working week from start to finish.
-
Day 1
Kick-off
A call of about 45 minutes, in which you show us what the software does and who uses it, and we agree the access we need.
-
Days 2 to 4
Review
One of us reads the code, runs the automated scans, tests a copy under load and looks over the hosting.
-
Day 5
Report and walkthrough
We send you the report and go through it with you on a call. It is written in plain English, with the technical detail in an appendix for whoever does the fixing.
Afterwards, the choice is yours: we can make the fixes for a fixed price, your own team can make them, or you can carry on building with AI and put Oversight in place, so that nothing reaches production unchecked again.
Questions
Questions you may want to ask before you book.
Will you tell us to rebuild it?
Rarely. Most AI-built software is a handful of fixes away from being ready. If a rebuild really is the cheaper route, we will explain why, and what it would cost.
Do we have to stop using AI?
No, and we would be the last people to suggest it, as we use AI tools every day ourselves. The report usually includes some rules you can give your AI assistant, so that it stops making the same mistakes.
What if it is fine?
Then we will say so in writing, with the evidence, which is useful to have when a client, an insurer or your manager asks.
What do you need from us?
Read-only access to the code (an invitation to the repository, or a zip file, is fine), a description of the hosting, and about an hour of someone's time across the week. We never need your production passwords.
Is our code safe with you?
We will happily sign your NDA (non-disclosure agreement) if you have one. Your code is held on encrypted company machines, used only for the review, and deleted when you ask or 30 days after the report.
Can you fix what you find?
Yes. The report comes with a fixed quote for the fixes, though you are just as welcome to hand the list to your own team, or to carry on with your AI tool and have us check the result.
Who you'll talk to
- Chris
Technical Director and founder
Chris reads the code and the architecture, and you will deal with Chris directly, from the first call to the final walkthrough.
Book
Book a Readiness Review.
Tell us what you have built and how. We will reply within one working day with a fixed price, a start date and details of the access we need.
- Price
- From £1,500
- Turnaround
- 5 working days from access
- Commitment
- None until you accept the quote