A production readiness audit is an independent review of a system before it carries real users, real money or real regulatory exposure. It answers one question honestly: if this went live on Monday, what would break, who would notice, and how long would it take to recover?
Where the single points of failure are, and whether degradation is designed or accidental.
Whether backups exist and whether a restore has ever actually been performed.
Whether you would notice a problem before your customers do, and whether alerts reach someone who can act.
Secret handling, authorisation coverage, and whether standing credentials survive a person leaving.
Teams rarely need to be told that reliability matters. What they need is someone outside the delivery pressure to look at the system without the assumptions the team has been living inside for months.
Why an independent review finds things the team cannot
The people who built a system are the worst placed to audit it, and that is not a criticism of their skill. They know how it is supposed to work, so they read the code that way. They have normalised the manual step in the deploy, the alert that always fires, the one server nobody reboots. An outside reviewer has no such normalisation, and asks the naive question that turns out to matter.
What we examine
- Architecture and failure modes. Where the single points of failure are, what happens when each dependency is slow rather than down, and whether degradation is designed or accidental.
- Data safety. Whether backups exist, whether a restore has ever been performed, and whether recovery objectives match what the business actually assumes.
- Observability. Whether you would detect a problem before your customers do, and whether alerts reach someone who can act.
- Security posture. Secret handling, authorisation coverage across every route, dependency risk, and whether standing credentials survive a person leaving.
- Performance under real load. Behaviour at realistic data volumes and peak traffic, not on a developer laptop with an empty database.
- Release and rollback. Whether you can deploy repeatably and reverse a bad change quickly under pressure.
- Operational ownership. Who owns the service, who is on call, and what happens at 3am on a public holiday.
How the engagement runs
We read the code and the infrastructure definitions, interview the engineers who built it, and exercise the system rather than taking documentation at face value. Where a claim cannot be demonstrated, we record it as unverified rather than assuming it holds. That distinction is the whole value of the exercise.
You receive a prioritised findings report: what blocks launch, what needs an owner and a date, and what is acceptable risk to carry knowingly. Each finding carries the evidence behind it, so your team can act without re-deriving the problem.
When to commission one
- Before a first production launch, especially where the system handles payments, personal data or safety-relevant decisions.
- Before a significant scale-up, where the load profile is about to change by an order of magnitude.
- After inheriting a system, whether through acquisition, a vendor handover or a team change.
- After an incident, where the goal is finding the class of problem rather than the single cause.
- Ahead of a customer or regulatory due diligence process, where you would rather find the gaps first.
Work through the production readiness checklist first if you want to self-assess. When you want an independent view, talk to our engineers.