Tomás had been freelancing for a little under a year when a mid-sized logistics company offered him what looked like the contract of his dreams: a long retainer to rebuild their whole deployment setup. The money was tempting. The scope was enormous. And somewhere around the third video call, a quiet voice in his head asked, “What if I find out in month two that this is not the work I thought it was?” What he did next is a lesson in how to start a freelance DevOps engagement with a small trial project, and it comes with a checklist you can borrow.

The temptation of the big signature

Remote freelancers live with an odd pressure. Work arrives in lumps, and a large retainer feels like safety. So you say yes to the whole shape of it, including the parts neither side has examined. Months later you discover the client’s staging environment is a rumour, the person who signs off changes has never read a pull request, and the “simple migration” depends on a server nobody can log in to.

Tomás had lived through a version of this before, so he proposed something different: a short, clearly bounded first project on one real system, with a written definition of success, after which both sides would decide together whether to continue.

What he put in the proposal

The client was surprised, then relieved. A trial let their own team test the working relationship without committing the budget for the entire programme. Tomás wrote it up in a page and a half.

• One system, chosen jointly: the internal reporting service, important enough to matter and isolated enough to be safe.
• A fixed time window with a review date agreed in advance.
• A fair, clearly stated fee for the trial work. It was not a favour or a giveaway; he treated it as real work from the first day.
• A yes/no test for the end of the trial, written by both parties.
• An explicit statement that either side could choose not to continue, with no hard feelings.

The checklist: auditing a trial before you sign it

Here is the version Tomás now keeps in a notes file. Use it as an audit of any trial proposal, yours or a client’s.

1. Is the scope one thing you can name in a sentence? “Move the reporting service to automated deploys” passes. “Improve their infrastructure” does not.
2. Does the client have a person who can answer questions within a working day? A trial with a silent counterpart teaches you only that the project will stall.
3. Is access sorted before day one? Credentials, repositories, a test environment. If getting these takes the whole window, that is information.
4. Is the pass mark written and agreed by both sides? Examples: the service deploys through the new path repeatedly without hand edits; the rollback has been exercised once; the client’s engineers can run it without you.
5. Is the review date in both calendars? Reviews that float tend to evaporate.
6. Is the exit clean? If the client says no, what do they keep, what do you hand over and how?
7. Are you paid fairly for the work? A trial should shrink risk for both sides, not turn the freelancer into unpaid labour.
8. Does the trial resemble the real engagement? If the sample is far easier than the main job, passing it proves little.

How it played out

The first week surfaced the very thing Tomás had feared: the reporting service relied on a cron job running on a laptop under someone’s desk. In a full-scale engagement that discovery would have arrived in the middle of a deadline. In the trial it became part of the work. They moved the job, wrote it down and the client’s team learned something about their own estate.

At the review, the pass mark was met on two points and missed on a third: the client’s engineers still could not run the deploy without help. Rather than treating that as failure, they agreed to extend the scope in a second, equally bounded stage, focused on handover and documentation. The retainer did eventually happen, but it was shaped by what the trial had shown, and it looked different from the original, vague proposal.

Where this idea connects to other freelance habits

Anyone juggling client work and a main job will find this site’s article on taking on DevOps projects responsibly next to a day job a good partner to the trial approach, since a small first engagement is far easier to fit around other commitments. And for those who are just starting out, the common questions beginners ask when they begin freelancing in DevOps cover contracts and first clients in more detail.

A note on the engineering side

The same logic applies to the technical work inside an engagement. When a client wants a large migration, freelancers often suggest moving one service first. Bigger organisations may call on a firm like DevOps Consulting India to sequence their migrations and implementations phase by phase; a solo engineer can borrow that sequencing habit at a smaller scale.

Pricing the trial without underselling yourself

Freelancers often worry that a small first project means a small fee, and that the smallness will anchor every later conversation. Tomás handled it by pricing the trial on the same basis as his normal work, scaled to the shorter scope, and by describing it as a defined phase rather than a discount. The client saw a professional offering a sensible first step, and the later retainer was negotiated on its own merits once the trial was over.

He also recorded what the trial cost him in time compared with his estimate. That record made the next proposal sharper, because he now had a real figure for how long onboarding, access and review meetings take with a client of that kind.

Keeping the story honest in your own records

After each trial, write a half-page summary for yourself: what the client said they wanted, what the work actually revealed, where the pass mark held and where it did not. Over a handful of engagements these notes become a quiet competitive advantage. They show you which kinds of clients value staged work, which scoping mistakes you repeat and which questions to ask before the next call. Freelancing rewards people who learn from every engagement, and a trial gives you a clean, bounded sample to learn from.

A final practical point: send the written pass mark to the client by email before the work begins, and ask for a one-line reply confirming it. It takes a minute and it saves an argument later, because nobody can claim they imagined a different finish line.

Red flags a trial can reveal early

• The client keeps moving the success criteria after work begins.
• Nobody can say who has authority to approve production changes.
• Payment terms for a modest first phase are already vague.
• The team treats you as a replacement for their own engineers instead of a partner who hands things over.

None of these is automatically fatal, but each is much cheaper to see during a short trial than in the sixth month of a long contract.

What Tomás tells other freelancers

He is blunt about it. A trial feels slower on the day you propose it, and some prospects will decline. Those who accept tend to be the clients you want: they respect process, they value clarity and they are willing to decide with evidence. The ones who insist on everything immediately, with no review, often reveal a pattern that would have followed you through the whole engagement.

If you take one thing from his story, make it this: before you commit to a big piece of remote work, offer one small, paid, clearly bounded piece and write down what yes would look like. Then let the work answer the question for both of you.