Find what breaks before your users do.

No — and it's never a condition.

The report stands on its own: findings, the ranked fix list, and the exact config or commands for the quick wins. Most teams fix it themselves, and that's the outcome I write it for. Implementation is a separate conversation, after you've read it.

A written report, plus a 60-minute recorded readout call.

A shareable web page and a PDF export of the same document. However long the findings need. A system with three real problems gets a shorter document than one with fifteen — I'd rather send you six pages you act on than thirty you skim. Yours outright. Share it with your team, your board, or an acquirer — there's no per-seat licence and nothing stopping it going into a data room. That's the booking, not a budget — I don't end the call while your team still has questions. Out of scope is implementation: the teardown finds and prioritizes, it doesn't fix.

A scorecard across every domain reviewed, scored against a stage benchmark

Findings ranked by severity and by effort, each with the reasoning behind it

Quick wins with the actual config or commands, not a description of them

A 30/60/90 roadmap and a risk register you can hand to whoever owns the fix

The clock starts when working access lands, not when you book.

The week starts the day working access lands, not the day you book. If access is delayed on your side, the window moves with it — the price doesn't change and neither does the scope. You'll get a written confirmation the day I start, so there's no ambiguity about which week the engagement is in.

A read-only role, scoped by you, revoked at the readout.

Everything I do lands in your own audit log. Nothing is copied out; anything I reference appears in the report as a finding. Access is revoked at the readout and there's nothing left to clean up. If your policy won't allow read-only access at all, a screen share works instead. It costs your engineers hours mine wouldn't, so it's the fallback, not the default.

AWS —

An IAM role assumable by my account with the AWS-managed `ReadOnlyAccess` and `AWSBillingReadOnlyAccess` policies attached. No admin, no write, no `iam:PassRole`. Billing read is there for one reason: finding cost drivers with a mechanism behind them, not a guess.

GCP —

`roles/viewer` plus `roles/billing.viewer` at the project or folder level. No editor, no owner. Same reason as AWS — cost findings need to trace to an actual resource, not a hunch.

Azure —

The built-in `Reader` role at subscription scope, plus `Cost Management Reader`.

Kubernetes —

A `ClusterRole` bound to `view`, plus read on `pods/log`. No exec, no port-forward, no secrets read — I don't need secret values to find out where they're stored wrong. The log read is so an incident-readiness finding is based on what actually happened, not what the manifests claim should happen.

Repos & CI —

Read access to the repos that build and deploy the system. Read on your CI project or org so I can see run history.

Observability —

Read-only seats on whatever you already run — Datadog, Grafana, Sentry, CloudWatch.

Yes for anything cloud or PaaS; no for a short, honest list.

AWS, GCP, Azure, Kubernetes anywhere (EKS, GKE, AKS, self-managed), and the PaaS layer — Render, Fly, Railway, Vercel, Netlify, Supabase, Neon, PlanetScale. Multi-cloud and hybrid are fine, and usually more interesting: the seams between two providers are where the expensive failures live. Bare-metal and on-prem I'll take if the deploy path is containerised and there's something to read. Mainframe, embedded and anything air-gapped I'll turn down — that's not my depth and I'll say so before you pay. Worth knowing up front if you're AWS-first: my production depth is GCP and GKE. AWS is reference-architecture work — Terraform, EKS, ArgoCD, built and published as source, not run against real traffic. I'll read your AWS setup the same way; I just won't pretend the depth is identical.

No. It's a production-readiness review.

How you deploy, scale, observe and spend — and where that's fragile. I'll flag security posture I can see, like exposed secrets or missing access controls, but I don't run scanners or probe your systems, and this isn't SOC 2 or compliance work. If security is your main concern, flag it in the intake questionnaire and I'll weight the review that way.

The review reads your repo only, and covers the deploy path.

Your deploy path, end to end: CI/CD pipelines, Dockerfiles and build context, Kubernetes manifests, IaC hygiene, secrets handling, and rollback safety. It cannot tell you what breaks first under load, how you scale, or where the cloud bill leaks. Those need running infrastructure and cloud access, which is the teardown. The review is credited in full against the teardown for 60 days.

Then that's the finding, and you get it in writing.

Then that's the finding, in writing, with what I checked and why it holds — which is the thing you actually wanted to know and the document your next diligence conversation needs. I'd tell you that plainly rather than pad the report to justify the invoice. If you'd rather have the money back than the reassurance, the refund stands.

Just over a year in DevOps, and I wrote application code before that.

Which is exactly why the sample report is ungated and the reference build is public source. Read them and judge the work — that's a better test than my years, and it's why I don't gate any of it.

Yes — I'm happy to review and sign your standard NDA before access is provided.

Signed before I get access, not after. I read what I sign — so if a clause is genuinely unusual I'll tell you which one and why, rather than quietly not signing it. No NDA of your own? A standard mutual one is fine.

Not without your written permission — and it's never a condition of the price.

I never publish a client's architecture, findings, company name, or engagement details without explicit written permission. That holds at every price, including the founder rate, and it isn't something you have to ask for or trade anything away to get.

Contractor agreement, IP assignment, W-8BEN — all standard, all fast.

I sign your contractor agreement, your MSA, or a plain SOW — whichever your process wants. Work product and IP assign to you on final payment. I invoice as a non-US sole proprietor, so a W-8BEN covers your side, and I'll send whatever else your AP system needs to open a vendor record.

Access is revoked the moment the engagement wraps.

Since it was read-only, there's nothing to clean up beyond removing the role. I don't copy your code or data out — anything I reference lives in the report as a finding. Happy to delete my working notes on request.

You hear about it that day.

I don't sit on a critical issue until the readout. An exposed secret or an open door to production gets a message with enough to act on immediately. Report in your inbox within one week of access.

One engagement at a time, and the schedule is built around yours.

The teardown is designed so my hours and yours barely have to touch: intake is a written questionnaire, the work in the middle is heads-down, and the only scheduled call is the readout — which lands inside your working day. If I can't hold the window, you'll hear it before you pay rather than after.

No — anything live is scheduled in your working day, wherever you are.

I'm in Pakistan, and I flex hours for anything that needs both of us present. Intake is written, so the readout is the only scheduled call — booked inside your day, not mine. The work in between is heads-down, so the overlap matters less than it sounds.

50% at booking, 50% on delivery. Full refund, no questions asked.

You'll get an invoice with a card or US bank-transfer link — the same way you'd pay any US vendor. Prefer Payoneer, Wise, or direct wire? Those all work too; just say so and I'll send details. The invoice goes out when you book, and the report lands within one week of access either way. The refund is the whole engagement, booking deposit included. You keep the report either way — I'm not going to ask for a document back.

For the right team, yes.

Fully remote, working with US or EU teams. I'd rather work together on something small first, so you and I both know before either of us commits — which is what the review and the teardown are for either way.

Typically $4,000–$6,000 for a 2 weeks block, quoted before you commit.

The teardown is fixed because I already know what it costs me to do. A sprint is scoped from a ranked list you've already read — so you get the number in writing before you commit, and it doesn't move afterwards. A written checkpoint each week: what shipped, what's next, what moved. If a week slips on my side the block extends at no cost to you — the quote is fixed, so a slow week is my problem, not a change order. I take one at a time for exactly this reason.