Second Opinion as a Freelancer: A Primer for Risky Client Work

Freelance DevOps work has one built-in weakness: there is nobody across the desk. In a company, a risky change usually passes through a teammate, a lead or a change board before it touches production. As a solo contractor, you are often the designer, the implementer and the approver at once. This primer explains how to get a second opinion as a freelancer before the handful of client changes that cannot be undone, what to send the reviewer, how to pay for it, and how to handle a reviewer who disagrees. Unfamiliar jargon is defined in a brief glossary near the bottom.

Why solo work needs a second opinion as a freelancer

Most of your work is reversible. A pipeline tweak can be rolled back, a dashboard can be rebuilt, a misconfigured alert can be edited. Those tasks do not need anyone else’s eyes.

A few tasks are different. Migrating a client’s production database to a new engine, deleting an old cloud account after consolidation, rotating every credential in an organisation, or changing DNS for a domain that handles payments: get any of these wrong and there is no quick undo. Worse, as a freelancer the consequences land on you personally, in your reputation, your reviews and possibly your contract liability.

You also carry a bias that is easy to miss. You quoted the job, you planned the approach and you want to deliver on time. That makes you the worst-placed person to spot the hole in your own plan.

Which jobs should trigger an outside review

Keep the rule simple so you actually follow it. Ask for an independent review when a change meets two tests:

It is hard or impossible to reverse within the client’s tolerance for downtime.
The impact of failure is serious: data loss, revenue loss, a security exposure or a breach of the client’s own obligations.

If a job passes only one test, a careful self-check is usually enough. If it passes both, find a second reviewer before you schedule the change window.

Finding the right reviewer

The reviewer’s value comes from independence, so pick carefully:

Choose someone with real experience in the specific technology, not just general DevOps knowledge.
Make sure they have no relationship with the client and are not competing for the same contract.
Prefer someone who will be blunt. A reviewer who wants to be liked is not much use.
Agree on a short, paid engagement. Free favours get skimmed; paid reviews get read.

A one-off review is not the same as ongoing mentoring or a networking circle. You are buying a single, focused read of one plan. If you are building wider professional relationships, our guide to growing a dependable circle of contacts as an independent engineer covers that side. This is narrower.

What a review costs, and why it pays

Expect a focused review of a single runbook to take an experienced engineer a few hours, sometimes a day for a complex cutover. Price it like any other specialist time. Some freelancers swap reviews with a trusted counterpart in a different niche, which keeps costs down, but treat the arrangement formally: a written scope, a deadline and a clear statement that the reviewer has no claim on the client.

Set that cost against the alternative. A failed one-way change can mean an unpaid weekend of recovery work, a refund demand, a bad review on a marketplace profile, or a client who quietly never calls again. For a solo business, any one of those can outweigh years of small savings on review fees. Seen that way, the review is less an expense than cheap insurance on your reputation.

Clearing it with the client

Never share client systems or data with a third party without permission. Before you approach a reviewer:

Tell the client you want an independent check before the irreversible step, and explain why it protects them.
Confirm in writing what the reviewer may see, and whether a non-disclosure agreement is needed.
Decide who pays. Many freelancers build a review line into the quote for high-risk jobs from the start.

Most clients respond well. It signals that you take their production environment seriously. If you are drafting the contract now, the advice in our piece on agreeing DevOps contract terms with clients applies: name the review step explicitly so nobody is surprised.

What to send the reviewer

Keep the pack tight. Reviewers have limited time and the quality of their answer depends on what you give them.

The decision in one sentence. For example: “Cut over the client’s primary PostgreSQL instance to a managed service on Saturday night and remove the old server on Monday.”
The runbook, step by step, including the exact commands you plan to run.
The rollback plan, and the point after which rollback is no longer possible.
Your assumptions: things you believe but have not proven, such as “no application writes directly to the replica.”
Relevant evidence: architecture sketch, sizing, test results from a rehearsal.

Do not send a polished pitch. Send the real plan, including the bits you are unsure about.

When the reviewer disagrees

The point of the review is to catch what you missed, so a disagreement is a good result, not a bad one. Work through it calmly:

Ask for reasons, not just a verdict. “I would not do it this way” is not actionable; “the replica lag during your rehearsal suggests the cutover will exceed the window” is.
Separate facts from preference. If the reviewer simply prefers a different tool, that may not matter. If they have found a factual gap, it does.
Test the disputed point if you can. A quick rehearsal often settles a disagreement better than a long call.
Put the final decision with the client when the trade-off is about risk appetite, and give them both views in writing.

The habit outside our industry

Second opinions are most familiar from medicine, where someone weighing a major procedure may have a different specialist go over identical reports. Online health services such as MyMedicPlus, a health and medical-travel information site, include a way to request that kind of review of an existing diagnosis. This blog cannot judge any medical finding, and only qualified professionals should. The example appears purely as a reminder that asking twice before a serious, permanent step is normal in fields that take risk seriously.

Mini-glossary

One-way door: a decision that cannot be reversed cheaply once taken, such as deleting a data store.
Two-way door: a choice that is cheap to undo, like flipping a feature flag back off.
Change window: the agreed period in which a risky change may be made, usually when traffic is low.
Rollback point: the last moment in a runbook where you can still restore the previous state.
Blast radius: how much of the client’s system or business is affected if the change fails.
Rehearsal: a full run of the change against a copy of production, used to test timing and steps.
Reviewer of record: the named person who read the plan and gave their view, noted in your change log.
Sign-off: the client’s written approval to proceed after seeing the plan and any review notes.

Practical checklist

Flag high-risk, irreversible jobs at the quoting stage.
Budget a paid, independent review for those jobs.
Get written client permission before sharing anything.
Send a lean, honest pack: decision, runbook, rollback, assumptions, evidence.
Record the reviewer’s notes and your response in the change log.
Let the client make the final call on risk trade-offs.

New to contracting and still finding your feet? Our starter questions for engineers going independent cover the basics. Once you are taking on production work, add the second-review habit early. It costs a few hours per risky job and protects the thing a freelancer depends on most: a clean track record.