An outside read on an architecture decision, a stack choice, or a company you are about to buy, written so you can act on it.
A review is worth paying for when the people closest to the system can no longer be the ones to judge it, either because the decision splits the team or because somebody outside needs an answer they can rely on.
What you get is a document with the evidence in it: what I looked at, what I found, what it will cost to leave as it is, and what I would do. Where I am not sure, it says so. A review that agrees with whoever commissioned it is worth nothing, and everyone in the room knows it.
ICF is early, so there are no named client logos here yet. What there is: public code you can open and read, and work described without naming whose it was.
01
Scope
What decision this has to support, and by when. A review without a decision attached becomes a document nobody reads.
02
Read and interview
The code, the infrastructure, the incident history, and the engineers. The incident history is where the honest version lives.
03
Write it down
Findings with evidence, options with costs including doing nothing, a recommendation, and what would change my mind.
04
Defend it
A session where the team takes the findings apart. Anything that does not survive that does not belong in the document.
A re-architecture decision has split the team for weeks
You are acquiring a company and the diligence has to be technical
A vendor is recommending the thing the vendor sells
The people who can judge the system are the people who built it
Tell me what you are running and what is slowing you down. I reply within one business day, and I will say so if this is not work I should take.
Taking a small number of contracts