$ ./audit.sh
Production Readiness Audit
Five days, fixed price, and a written report that tells you exactly what will break in production and in what order to fix it.
Who this is for
Teams running — or about to run — an AI or cloud system they did not fully build themselves. Often AI-assisted codebases, inherited systems, or a product that worked as a prototype and now has customers.
The pattern I see most often: the system works. It demos well. Then it meets real users, real volumes and real edge cases, and starts failing in ways nobody on the team can explain — usually at the seams, where long-running work, retries and third-party APIs meet. That is a diagnosable problem, and five days is enough to diagnose it properly.
What gets examined
- →Execution paths — which code actually runs in production, and which is legacy or experimental. Usually the first surprise.
- →Durability — what happens to long-running and background work when a request times out, a worker dies, or a provider goes down.
- →Idempotency and data integrity — duplicate and out-of-order events, partial writes, and records that look valid but are not.
- →AI layer, where there is one — whether outputs are validated, whether the system can assert something it did not do, and whether user-supplied content can steer it.
- →Access and secrets — least privilege, credential handling, what an attacker reaches from each entry point.
- →Deploy and rollback — whether a bad release can be reversed, and whether staging is genuinely isolated from production.
- →Cost — what you are spending, on what, and the largest avoidable line.
What you get
- ✓A written report: every finding with evidence, ranked by what will hurt first — not an alphabetical checklist.
- ✓A reproduction for each critical finding, so your team can see the failure rather than take my word for it.
- ✓A 30/60/90 remediation plan, scoped so you can hand it to your own engineers.
- ✓An architecture diagram of what you actually have, which is often not what you think you have.
- ✓A one-hour walkthrough call, recorded, so the people who were not on it can still watch.
What this is not
- ·This is not a penetration test or a compliance certification.
- ·No code is changed during the audit. Remediation is a separate engagement, and you are free to do it in-house — the report is written so you can.
- ·Not a code-style review. Findings have to affect reliability, security or cost to make the report.
How I work, in public
You should not have to take my word for any of this. I publish the same kind of analysis on systems I build myself — architecture, deliberate failure drills, measured numbers, the bill, and the guardrails that did not hold. Read one before you decide.