I read your codebase and tell you what will break first in production, with the fixes ranked by what it costs you to ignore them.

You have something that works on staging and you are about to put real users and real money behind it. This is the read-through before that happens. I go through the API end to end and come back with a written report: where a request can be processed twice, what happens when a dependency times out, which queries have no bound on them, where errors are swallowed, and what your logs will not tell you at three in the morning. Every finding comes with the failure it actually causes - concrete input, concrete consequence - not a style opinion.

Findings are ranked by cost of ignoring them, and each carries a fix I would write myself. Roughly a third of what I find is usually a one-line change, and that third is the part worth doing before launch.

You send me read access and a paragraph on what the service does. I do not need a meeting to start, and you get the report whether or not you like what it says.

What I do not do: rewrite your architecture, argue about frameworks, or pad the list. If the code is in good shape, the report will be short and I will say so.