Application review

What this is

Software arrives without a reliable account of itself more often than not — the contractor moved on, the original developer left, or it was generated quickly and nobody has read all of it. The question in every one of those cases is the same: can this be trusted in production, and if not, what has to change first?

What you get

• What it actually does. A reconstruction of the system's real behaviour from the code as written, rather than from the documentation or the original intent.
• How the critical paths hold up. The routes that write data, touch money, or run unattended, exercised rather than reasoned about.
• A risk-ranked list of what to fix first. Ordered by what it costs you if it fails, not by how easy it is to fix.

What I won't do

I won't hand you a severity score without telling you what it was measured against. Every finding names the specific condition under which the system misbehaves, so you can check it yourself or hand it to whoever maintains the code. A finding you can't verify isn't worth acting on.

This is the same discipline the build work runs under — see how I work.

When it's the right call

• An application built quickly — by AI tooling or a contractor — that you can't yet trust in production.
• An integration that keeps failing, or one nobody wants to touch.
• A system you're about to take ownership of and want read before you do.