A freelance DevOps engineer carries something a salaried colleague does not: personal exposure to every irreversible mistake. If a production change goes wrong at a client, you cannot lean on a team, a manager or an incident rota. That makes reversible decisions a working discipline rather than a nice idea. What follows is an audit checklist you can run against your own practice, covering client work, contracts, access and your business choices, with the aim of keeping undo available wherever it is cheap.

Running the audit

Take one live engagement and walk every section with it in front of you. For every item, answer yes, no or not applicable, and write one line about what you would change. Items answered “no” are not failures; they are places where you are quietly relying on nothing going wrong. Prioritise the ones where the downside is large and the fix is small.

Section 1: changes you make to client systems

1. Every change has a written way back. Before touching a client’s pipeline, cluster or DNS, you can put the restore path into a couple of lines. Unable to phrase it? Then the change is not ready to be made.
2. Configuration lives in version control. Whether it is a repository you own or the client’s, the previous state is recoverable as a diff, not as your memory.
3. You have rehearsed the rollback at least once. A rollback never tried is a theory. If the client’s environment allows a staging copy, try it there.
4. Risky changes sit behind a switch. A feature flag, a weighted route or a gradual rollout means you can reduce exposure without a redeploy.
5. Data changes keep the old shape alive. You add before you remove, and the removal is scheduled separately with a snapshot taken immediately before.
6. You choose your timing. Changes avoid the hours when the client’s staff are least available to help you reverse them. A Friday evening change with a client team offline is a one-way door in disguise.

Section 2: access and credentials

1. Your access is revocable by the client in minutes. Named accounts or scoped roles, never shared logins, so ending the engagement does not require untangling anything.
2. You never hold the only copy of anything. Secrets, keys, recovery codes and documentation stay in the client’s own vault.
3. Your permissions are the narrowest that work. Broad rights make errors larger and harder to contain.
4. Temporary elevation expires on its own. If you need administrator rights for a task, they lapse afterwards without anyone needing to remember.

Section 3: contracts and commercial terms

1. You can leave, and so can they, on defined notice. A clear, fair notice period in both directions turns a bad fit into a minor event instead of a dispute.
2. Scope changes are written down before work starts. A change of direction agreed in a chat message is easy to forget and hard to prove.
3. Deliverables are handed over in pieces. Interim handovers mean that if the engagement stops early, the client holds something usable and you hold something payable.
4. Long retainers are earned, not assumed. A twelve-month commitment signed before either side knows the working relationship is a locking door for both. Shorter terms with renewal are easier to correct.
5. Your own tool and subscription commitments are monthly. Avoid annual plans for software you have not yet used on a real engagement, unless the saving clearly outweighs the lost flexibility.

The long-term trust side of this is covered in winning over a client who has never worked with you, and clear terms are a large part of it. Clients relax when they see that stopping is as orderly as starting.

Section 4: your own business choices

1. Specialisation is tested before it is announced. Before rebranding yourself as a Kubernetes-only or security-only specialist, take two or three engagements in that area and see whether you enjoy them and whether the work arrives. A public repositioning is easier to make than to unmake.
2. Rates can move. You should be able to raise a rate for new clients without renegotiating existing ones, and you should know in advance which clients are on legacy terms.
3. Your income does not rest on one client. A single dependency turns every disagreement into a high-stakes event. Spread the risk before you need to.
4. Your savings buffer buys you the right to say no. Walking away from a bad engagement is itself a reversible decision only if you can afford a gap.
5. Leaving a full-time job is a staged step if possible. The advice on running a side practice while employed full-time is a good illustration of reducing the jump into steps, subject to your employment contract.

Section 5: the one-way list

A few decisions in freelance life cannot be taken back, and the audit should name them so they receive full attention.

• Deleting or destroying client data, even when asked to do so, without a confirmed backup and written instruction.
• Publishing client information, including naming a client in marketing without permission.
• Running destructive commands against a production environment.
• Signing a long exclusivity or non-compete arrangement.
• Giving up intellectual property you meant to keep.

Each deserves a pause, a second check and, where possible, written confirmation. These are the places where evidence beats speed.

A note on learning from established practice

Freelancers do not work in isolation, and the habits above come from mainstream engineering practice around releases and operations. DevOpsSchool Netherlands, a consultancy and training company in Amsterdam working on DevOps, reliability and cloud, publishes free playbooks and tutorials and also places freelance and contract talent across Europe, so it is a useful reference for how organisations think about the contractors they bring in. Reading how clients evaluate contract engineers helps you anticipate what they will want from you.

Scoring yourself

Count the “no” answers per section. Do not chase a perfect score; chase the highest-leverage fixes. In most practices, two or three small changes remove most of the exposure: a written rollback note for every change, named and revocable access, and a notice clause in every agreement. Those cost little and shift the odds heavily in your favour.

An example of the audit in action

Consider a contractor hired to move a client’s build jobs to a new pipeline system. Against the checklist, the first gaps are obvious. The old jobs are the only record of how builds run, so the contractor copies their definitions into a repository before anything else. The new pipeline is wired to a staging branch, with the old jobs left enabled beside it. Access is granted through a named role the client can remove with one click. The contract specifies fourteen days of notice either way, and the work is split into three handovers, one per product team.

Three weeks in, the client’s priorities shift and the project is paused. Because of the interim handovers, two of three teams are already on the new pipeline and the third keeps its old jobs, untouched and working. Nobody has to untangle anything. The contractor invoices for delivered pieces and keeps the relationship intact, so the client calls again when the pause ends. None of the precautions were dramatic; they were just chosen so that an interruption would not become a crisis.

Why this suits independents especially

A salaried engineer who makes a poor call is surrounded by colleagues, review processes and an employer with insurance and patience. An independent has fewer cushions, so the cheapest cushion available is the choice itself: pick the version of each decision that leaves room to reverse. It costs a little thought up front, and it keeps small errors from turning into reputational ones that follow you from one client to the next.

Make it a routine

Rerun the audit at the start of each new engagement and again every quarter. Engagements change shape, access accumulates, and a short-term arrangement quietly becomes long-term. A fifteen-minute review is enough. The aim is not to be cautious about everything; it is to stay quick and confident on the many reversible choices because you have been strict about the few that are not.