Audits that don't gather dust

The well-architected review is one of the most over-promised deliverables in cloud consulting. A firm comes in, runs a framework against your environment, and hands you a long PDF of findings color-coded red, amber, and green. It looks thorough. It cost a lot. And six months later it's in a shared drive nobody opens, because it was written as a document to be received rather than work to be done.

We do reviews — security reviews, cost reviews, well-architected audits, migration assessments. We just refuse to do the version that gathers dust. A review is only worth what gets acted on, so we write the findings as work you can act on.

Cost models before code, not after the bill

Start with cost, because it's where the dusty-PDF problem is most expensive. The usual pattern is to build the thing, run it for a quarter, get surprised by the bill, and then commission a cost-optimization review that produces a list of things you should have done at design time. By then the architecture is set, the easy savings are structural and hard to retrofit, and the review is mostly a catalog of regret.

We build the cost model before the code. Pricing is a design input, not a postmortem. When the architecture is still a decision rather than a deployment, the question "what will this cost at scale" changes what you build — you pick the managed service that pays its way, you avoid the pattern that looks elegant and bills like a yacht. A cost finding delivered before the architecture is set is a lever. The same finding delivered after is a complaint.

Findings written as tickets, not as a slideshow

When we do review an existing environment, the output isn't a graded report. It's prioritized, specific, actionable work — written the way we write everything else, as records and tickets that land in the repository beside the system they're about. Each finding has the context, the recommendation, and enough specificity that someone could pick it up and ship it without a follow-up meeting to decode what we meant.

The difference between "your IAM posture scored amber" and "this role has these excess permissions, here's the scoped policy, here's the PR" is the difference between a review you file and a review you do. We write the second kind. If a finding can't be expressed as concrete work, we're not sure it's a finding — it might just be an observation, and observations don't improve systems.

Migration plans you can execute

The same principle governs migration assessments. The dusty version is a sequence diagram of an idealized end state and a hand-wave about "phases." The executable version is a plan with the real ordering of dependencies, the cutover that actually has to happen, the rollback if it doesn't, and the parts that are genuinely hard called out as genuinely hard rather than smoothed into a confident timeline. A migration plan is a promise about reality; we'd rather make a smaller promise we can keep than a grand one we can't.

The honest review includes "don't"

A review worth having will sometimes tell you not to do something — not to migrate the workload that's fine where it is, not to adopt the service that's trendy but wrong for your shape, not to spend the optimization effort on the line item that's already small. A review that only ever recommends more work is selling, not assessing.

We run the same patterns on our own products that we'd recommend in your review, which is the test that keeps the advice honest: we don't suggest an architecture we wouldn't run, or a cost tradeoff we haven't lived with. A review is a piece of senior judgment delivered as actionable work. Delivered any other way, it's just a PDF.

---

Have a review you paid for and never acted on? Start a conversation.