If you want to start freelancing as a DevOps engineer, you will hit a wall that has nothing to do with Kubernetes: you do not know what to sell. So you read, you compare rates, you redraw your service list, and you tell yourself you will launch once the website and the portfolio look right. Months later you have a nice website and no client. This explainer is blunt about what to do instead. Put a small, clearly bounded first offer in front of real people now, deliver it well, and let the first few jobs tell you what the real offer should be.
What a “first version” of freelance work actually is
It is one service, described in plain language, with a fixed scope and a short timeline. For example: “I will set up automated builds and deployments for one application, with a written handover, in two weeks.” It is not a full DevOps retainer, a menu of twelve services or a promise to transform your company’s engineering culture. It is the smallest thing a stranger can understand, say yes to and judge afterwards.
The point of keeping it small is not modesty. Small offers are easy to explain, easy to price, easy to finish and easy to get a testimonial from. A buyer who has never worked with you can picture a two-week job. They cannot picture a vague ongoing relationship with someone they have not met.
Why waiting for the perfect setup backfires
Perfection in freelancing is a moving target because you cannot see what clients want until you talk to them. Every hour spent polishing in private is an hour spent guessing. Worse, guessing tends to push you toward big and impressive offers, which are exactly the ones that are hardest to sell. Real conversations correct this quickly. A founder will tell you in ten minutes that they do not care about your multi-cloud strategy; they just want deployments to stop breaking on Fridays.
- You learn the language buyers use, which becomes the wording of your next offer.
- You learn your real pace, so your later estimates are honest.
- You collect proof, which does more for credibility than any amount of self-description.
- You find out what you enjoy, which matters when the work is yours to choose.
How to build the first offer in an afternoon
- Pick one problem you have fixed before. Pipelines that need babysitting, flaky staging environments, no backups, slow container builds. Choose something you could do half asleep.
- Write one sentence for the buyer. Their problem, your fix, the timeframe. No jargon.
- Define what is not included. Out-of-scope items prevent most disputes. List three.
- Set a simple price. A fixed fee for the scope, or a clearly stated day rate with an estimate. Do not agonise; you will revise it after the third job.
- Decide how it ends. A short written handover and a call. Both are cheap and make the client feel looked after.
If you are still new to the whole idea of selling your time, the answers collected in a beginner-oriented round of answers for newcomers to independent DevOps work cover the practical basics, and none of them require you to wait.
A quick example makes it concrete. Suppose your first offer is automated deployments for a small web application. Job one takes three weeks instead of two because the client’s staging server was misconfigured. That is useful information: your next offer now includes a short environment check before the main work, priced separately. Job two goes smoother, and the client mentions that what they really needed was a rollback button. Your third offer is built around exactly that. Nobody could have designed that sequence in advance, which is the whole argument for starting.
Where the first client comes from
Almost always from people who already know you a little: former colleagues, managers you worked well with, community contacts, and friends of friends. You do not need an audience. You need five messages sent to five people saying what you now offer and for whom. Keep it light: “I am taking on one or two small automation projects a month; if you know a team stuck on deployments, I would be glad to help.” Building that circle is its own skill, and a good guide to growing a dependable network and finding people to learn from explains how to do it without feeling like you are begging for work.
Going slowly is fine while you have a day job
Many people test freelancing while employed. That is sensible, and it argues even more strongly for a small first offer: a bounded two-week project is far easier to fit around full-time work than an open-ended engagement. Check your employment contract first for rules on outside work, and keep any client work strictly separate from employer systems and time. The article on taking on freelance projects responsibly next to a full-time job walks through those boundaries in detail.
Show your work in the open
One cheap habit speeds everything up: write about what you do. A short post describing a problem you solved, with client details removed, is a better sales page than a list of skills. You do not need your own domain to start; a quick option is a free blogging site where each writer gets a subdomain to call their own, which lets you put a first post online today and keep improving it. Link to it when you message prospects. A rough post that exists beats a polished one that does not.
Common mistakes with a first offer
- Scope creep by kindness. You add “one small extra” and then another. Write extras down as a follow-on quote.
- Underpricing to be safe. A rate so low it signals doubt invites difficult clients. Price fairly for the scope.
- Skipping the written agreement. Even a one-page statement of scope, price, timeline and payment terms prevents most misunderstandings.
- Hiding the first job. If a client is happy, ask whether you may describe the work, anonymised, or quote a line of feedback.
- Staying too small forever. A first version is a starting point. After the third or fourth job, review what sold, what hurt and what you enjoyed, then redesign the offer.
The no-nonsense summary
You do not need a perfect brand to begin freelancing. You need one clear service, a short scope, a fair price and a few honest conversations. Do the work, ask for feedback, and revise. Within a handful of jobs you will know more about your market than months of private planning would have shown you, and you will have earned proof to stand behind the next, better version of your offer.
