Consulting with Docker and Kubernetes Skills: How to Start

Short answer: You do not need production experience to start consulting on Docker and Kubernetes. Containerise your own stack, publish it with a README that explains your decisions, and go where people are already complaining about broken deployments. Certifications help with procurement, not with getting your first client.

---

My first DevOps consulting job came from a man who was annoyed with me.

He was venting in a Discord server about a container that kept dying around two in the morning, every night, with no pattern he could see. I replied with the obvious guess: probably a memory limit, check the logs.

His response was short. Tried that, doesn't work, everyone says the same thing.

Which stung a bit, to be fair, because everyone probably had said the same thing. So I wrote a longer reply explaining that if the kernel was killing it, he'd see exit code 137 specifically, and where exactly that shows up.

Two hours later: "137. how much do you charge."

---

The certification question, which everyone asks first

Should you do the CKA. Is the Docker associate cert worth anything. This is the first question in every thread.

Here's my actual data. Three clients, no mention of certificates at all. The fourth asked, and only because a procurement person needed a line item for a form.

A certificate clears a filter when a client has no other way to assess you. It isn't proof of skill and clients know it, because passing an exam and fixing a cluster at 3am are visibly different activities.

But there's an upside nobody mentions. Studying for the CKA forced me through a pile of things I'd been quietly avoiding because they looked boring. Network policies. Resource quotas. RBAC. Left to myself I'd have kept skipping all three for another year.

So do it if you have the time. Just don't hold your pitching hostage to it, which is roughly what I concluded about AWS certifications too.

---

Building proof when you have no production history

This is where people get stuck. Clients want production experience, and production experience comes from clients.

I broke that loop with one repository.

A small stack: a Node app, Postgres, Redis, and nginx as a reverse proxy. Everything in Docker Compose, running from a single command. Then a Kubernetes version of the same thing with proper manifests. And a README explaining every decision I'd made and why. Why those resource limits. Why the health check was written that way. Why the secrets were handled the way they were.

The README took longer than the application. Around five hours of writing.

And that's the part that did the work. My second client told me straight out that the README was what convinced him, because it showed I made choices rather than pasted configs from a blog post.

It's the same principle as convincing clients with a GitHub portfolio, just in DevOps clothing. Nobody is reading your YAML line by line. They're checking whether you thought about anything.

---

Where the work actually comes from

Freelance job boards do carry DevOps listings. They're crowded and the rates are poor.

What worked for me was sitting where people describe their problems out loud. Discord servers, a few subreddits, two Slack communities. Answering properly and never mentioning money.

Four of my first five clients came from that. The fifth was a referral from one of those four.

It's slow. I'm not going to pretend otherwise. I gave it maybe 20 to 25 minutes most days, and something like one in 15 answers turns into a conversation that goes anywhere.

What it buys you is a conversation that starts after you've already helped. There's no pitch, no proposal, no competing against 40 other applicants. The person is stuck, you unstuck them, and the price conversation happens on completely different terms.

---

The most useful thing to tell clients: they don't need Kubernetes

This took me nearly two years to work out and now I say it in the first call.

Most small businesses asking for Kubernetes don't need Kubernetes. What they need is for the app to stop falling over at night, deploys that don't terrify them, and one server dying not taking everything with it. Those are three ordinary problems with much cheaper solutions.

One client had roughly 900 daily active users and wanted a cluster because an investor had told him it was necessary for scale. I told him Docker Compose plus a managed database would do everything he needed, and a cluster would cost him money and attention every month in exchange for nothing.

I genuinely expected to lose that job. I'd just talked myself out of the larger, better-paying version of the work.

He approved the smaller job that afternoon. Four months later, when his traffic actually grew, the bigger project came to me without a competing quote.

Telling clients the boring truth turns out to be commercially fine.

---

What the first paid project looked like

Rs 6,500, roughly nine hours of work spread across four days.

The scope: fix three misbehaving containers, set sensible memory limits, add health checks, and write a small script that alerted him when something restarted. Nothing clever anywhere in it.

The hard part wasn't technical. It was working inside someone else's setup, built by a person who had left, with no documentation of any kind. Two of those nine hours went purely on working out what was running where.

I also broke something. I renamed an environment variable I was confident was unused, and it turned out a cron job depended on it. His daily report didn't run the next morning.

I fixed it and told him before he noticed. That, oddly, is the thing he mentioned in his review, because apparently the previous contractor's habit had been to quietly fix mistakes and say nothing.

---

Pricing, and the mistake I made with hourly

I started at about Rs 900 an hour, which was wrong, though not for the reason people usually give.

The problem was that as I got better, the work got faster, and my income fell. A problem that used to take five hours started taking 40 minutes. I was being penalised for competence, which is a strange thing to build a business on.

Now I quote the project. Here are the three things I'll fix, here's the price. How long it takes me is my problem.

Hourly isn't useless though. For ongoing maintenance, where nobody can define the scope in advance, hourly or a monthly retainer is the honest structure and I still use it there.

---

What I'd do differently

Read less. Break more.

I spent about four months on videos. The full architecture, the control plane, etcd, the lot. I took notes I never reopened. Then I got in front of a real cluster that wasn't working and understood almost nothing. Three days on one problem.

I learned more in those three days than in the four months, because a broken thing in front of you makes you reason instead of recall.

So now I break my own setup deliberately. Delete a pod and watch what happens. Squeeze the memory limit until it crashes. It feels slightly silly, but the pattern recognition it builds is exactly what a client is paying for when they need you to say where the problem is within ten minutes of joining a call.

And honestly that's the whole product. They have Google, they have the docs, they have an AI that writes YAML. What they don't have is somebody who has watched this specific thing break before.