What a production-readiness audit should uncover
Before you spend real money hardening an app — AI-built, inherited, or years old — someone should be able to tell you, in writing, what you have and what it needs. That document goes by many names: production readiness audit, technical due diligence, code assessment. What matters is not the name but whether it answers the questions below. Use this as the checklist, whoever you hire.
Seven things the audit must answer
Production readiness is a checklist, not a feeling. An audit that skips any of these left real risk on the table.
- What happens to your data? Is there a real schema with migrations, or demo data in a structure nobody planned? Are there backups, and has anyone ever tested restoring one? A backup that has never been restored is a hope, not a backup.
- Who can touch what? Authentication and authorization examined honestly: what data you hold, who can reach it, and where the secrets live. Keys in the codebase or in a chat transcript should appear in the report as findings with severity, not footnotes.
- Does the money reconcile? If the app takes payment: what happens on failure, on refund, on webhook retry? Billing that only handles the happy path is an incident on a timer.
- Which integrations hold under stress? Every connection to another system, mapped: what retries, what monitors, what silently drops. Manual steps someone “just remembers to do” belong in the report, because they are where operations break.
- What does change cost? Test coverage measured against consequence: which parts of the system can be changed with confidence and which are change-and-pray. This single answer explains most of why development has been slowing down.
- How does software reach users? Staging, rollback, monitoring — or edit-production-and-hope? An app can run for months without a deployment story; it can’t survive its first bad release without one.
- Who actually owns everything? Repository, hosting, domain, database, every third-party account — enumerated, with who holds each credential. Ownership gaps are the most common nasty surprise in inherited and AI-built systems, and the cheapest to fix early.
What you should be holding at the end
Findings alone are not an audit; they’re a tour. The deliverable that justifies the fee has three parts. First, a risk register ordered by severity — not everything wrong, ranked, but what can hurt you soonest, first. Second, a prioritized plan: the sequence of work, with the reasoning visible, so a second opinion can check it. Third, a real estimate for the work behind the plan, so the next decision is a business decision instead of a leap.
And the whole thing should be yours. Portable, readable by another engineer, useful even if you never speak to the auditor again. An audit you can only act on by hiring its author is a proposal wearing an audit’s clothes.
How to spot an audit that’s really a pitch
Three tells, learned from cleaning up after them. No severity ordering — forty findings presented flat, so everything feels urgent and the auditor’s proposal conveniently addresses all of it. No price before it starts — an assessment with an open-ended meter running is not bounded diligence. A conclusion that never varies — if every audit the firm has ever run concluded “full rebuild, by us,” the audit is a formality. Rebuild is sometimes the honest answer; it is suspicious as the only answer. The keep-versus-rebuild question deserves evidence, which is the same argument we make in when a vibe-coded prototype needs senior engineering.
There’s a structural fix for the incentive problem, and it’s worth demanding: the auditor commits in advance to putting the verdict in writing even when the verdict is against their own interest. Ours is explicit — if the evidence says a rebuild beats a rescue, the report says so plainly, and the report is still yours.
Our version, priced and sampled
Our production-readiness audit is the Production Blueprint: fixed scope, starting at $2,500, most falling between $2,500 and $7,500 depending on the codebase, workflows, integrations, and stakeholder count. It covers the seven questions above and ends with the risk register, the plan, and the estimate. You can read a representative sample deliverable before spending anything — the same standard we’d tell you to hold anyone else to.
If the audit is step one of a larger job — an AI-built prototype heading to production, or a project a previous developer left behind — the follow-on paths are Prototype-to-Production Rescue and Software Project Takeover. And if the question on your mind is really about who should do the work, not what the work is, read why one developer is sometimes the wrong hire.
Want the seven questions answered about your app?
Joseph reads every note and replies himself. If an audit isn’t what you need, he’ll say so.
Start a Project