What a Production-Readiness Review Covers

Who the Review Is For

The review is for software a small team depends on and nobody has looked at closely since it went live. That is a lot of software. Most of it was never designed to be a system of record; it became one.

• A tool that grew up inside the business. An Excel workbook or Access database that became the system everyone updates, or an app someone built on a low-code platform or an AI app builder that now runs part of the operation.
• A system a vendor or developer left behind. The vendor closed, stopped answering, or raised prices out of reach, or the developer who wrote it left, and nothing is documented.

The name comes from site reliability engineering, where Google's SRE book describes a production readiness review as the check a service passes before the reliability team takes it on. We borrow the name and the habit of scoring with evidence, and apply it to business software that is already in production.

The Eight Areas We Score

Each area gets a score and the evidence behind it: what we looked at, what we found, and what good would look like. The areas are the ones that decide whether software can be relied on and changed, not whether it is elegant.

1. 1
   Access control

   Who can get in, and what they can do once they are in. We look for shared logins, accounts that belong to people who have left, and whether anyone can see or change data they have no reason to. Good looks like one account per person, roles that limit what each person can do, and a way to remove someone the day they leave.

2. 2
   Data integrity

   Whether the data can be trusted. We look for duplicates, totals that disagree between screens or reports, fields that accept anything, and rules that live in people's heads rather than in the software. Good looks like one record per thing, checks at the point of entry, and reports that reconcile.

3. 3
   Backup and recovery

   Not whether backups exist, but whether a restore has ever been tried. We check what is backed up, where the copies live, how old the newest one is, and what a restore would involve. Good looks like a backup that has been restored on purpose, recently, with the result written down.

4. 4
   Security

   How the software is exposed and how it is kept current. We check whether it is reachable from the internet, how it is patched, whether its platform and libraries still receive updates, and how secrets such as connection strings and API keys are stored. Good looks like a short list of what is exposed, a patch routine, and no credentials in plain text.

5. 5
   Maintainability

   Whether anyone other than the original builder can change it. We look for the source code, whether it is in version control, whether it builds on a clean machine, and how much of the behavior is written down. Good looks like a repository you own, a build that works, and notes a new engineer can follow.

6. 6
   Reliability

   How often it fails and who finds out first. We check error logs, restarts, scheduled jobs that stop without anyone noticing, and whether a failure reaches a person before it reaches a customer. Good looks like logging, a health check, and an alert that someone answers.

7. 7
   Limits on growth

   What breaks at twice the data or twice the users. An Access file approaching its 2 GB limit, a workbook that takes minutes to open, one user locking everyone else out, a report that times out. Good looks like known limits with headroom, and a plan for the first one you will hit.

8. 8
   Dependence on one vendor

   What you would hold if the vendor, the developer, or the platform disappeared. We check who has the source, the admin passwords, the domain, the hosting account, and the licenses, and whether the platform can export your data in a form another system can read. Good looks like everything in your name and a way out.

The Checklist to Run Yourself

One question per area. You do not need an engineer to answer them, and the answers tell you whether to book a review at all.

• Can you name every person who can log in, and did the last person who left lose access the day they left?
• Do two reports that should agree, agree, and does anyone know why when they do not?
• When did you last restore a backup, not take one, and did it work?
• Do you know whether the software is reachable from the internet, and when it was last patched?
• Is the source code in a repository you own, and has anyone other than its author ever changed it?
• When it fails, who finds out first: a monitor, an employee, or a customer?
• What breaks first at twice the data or twice the users, and how close are you to it?
• If the vendor or developer vanished tomorrow, what would you hold: the code, the passwords, the domain, the data?

The same eight questions work for software you are about to take on, such as a system that comes with a business you are buying or one another department is handing to you. Ask them before you sign. Every "not sure" is a finding, and so is any answer you cannot back with evidence. Most of what a review turns up is a specific gap with a specific fix, and the gaps that matter most are usually the cheapest ones: a restore test, a removed account, a repository.

What You Get at the End

The review ends with a readout session and a written report. You keep the written results whether or not you hire us. The report contains a systems and data inventory, a score for each of the eight areas above with the evidence behind it, and a risk list with the fix we recommend for each item. It closes with three priced options and a fixed-price offer for the next step. The options are usually some version of harden what you have, rebuild one workflow, or replace the tool, and the review fee is credited toward the build if you go ahead with us.

Most business software has never been asked these questions. The review asks them once, in writing, with evidence.

When the Builder Is Gone

When the vendor or developer who built the software is no longer around, the review starts with the eighth area, not the first: what you hold, and whether the source you hold matches what is running. Then backups, because a system nobody maintains is one disk failure from gone. Only then the rest.

If the code is missing, or the running version does not match any copy you can find, that changes the options, and the report says so. A takeover then starts with recovery rather than improvement; our guide on taking over an undocumented codebase describes that order, and Software Rescue & Takeover is the service that follows the review.

What the Review Is Not

It is not a penetration test and not a certification; the security area tells you how exposed you are and what to fix first, not that you are compliant with anything. It is also not a case for a rebuild. When the right answer is to keep what you have and fix two things, the report says that, and the priced options are sized to the findings rather than to what we would like to build.

Keep Reading