Most of our series-A clients arrive at the same crossroads. They have a working product, a single production VM, and a CTO who hasn’t slept through a deployment in six months. They know they need “DevOps,” but they don’t know what good looks like, and the consultants they’ve talked to all want to sell them Kubernetes.
We don’t sell anyone Kubernetes. We sell them a ladder, and we tell them which rung they’re on. This is what eight weeks looks like.
Week 1: containerize and document
Before touching infrastructure, we put the application in a Dockerfile. Not because containers are inherently better, but because they force you to write down the runtime contract: which OS packages, which runtime version, which environment variables, which ports. Half the time, this exposes a setup that nobody on the team can reproduce locally.
We also write the first runbook in week one. Three pages: how to deploy, how to roll back, how to read the logs. If a junior engineer can’t follow it on a Friday afternoon, it isn’t done.
Weeks 2–3: a deploy pipeline you can trust
The goal isn’t sophistication. The goal is that pushing to main produces a verifiable, rollback-able artifact in production within fifteen minutes. GitHub Actions or GitLab CI, build the image, tag with the commit SHA, push to a registry, deploy to a staging environment, run smoke tests, promote to production behind a manual approval.
The manual approval stays for the first month. Automated promotion comes later, when the smoke tests have caught their first real regression and the team has learned to trust them.
Weeks 4–5: observability before scale
This is where most teams get it wrong. They scale first, then try to debug a production incident with no metrics, no traces, and a tail -f on a single log file.
We install the boring stack: Prometheus for metrics, Loki for logs, Grafana for dashboards, OpenTelemetry for traces. Hosted alternatives if the team prefers — Datadog, Honeycomb, Better Stack. The vendor matters less than the discipline: every service emits structured logs, every endpoint records latency, every error gets a unique fingerprint.
The first dashboard we build has six panels: request rate, error rate, p95 latency, database connection pool, queue depth, and CPU/memory per service. If something is wrong, the answer is on that one page.
Week 6: alerting that doesn’t lie
Most teams have too many alerts. The CTO has muted the channel because eighty percent of pages are noise. We delete eighty percent of the alerts.
What survives is a small set of symptom-based alerts: the error budget for the public API is being consumed faster than expected; the queue depth is growing without bound; a deployment failed and rolled back. Each alert points to a runbook section. Each runbook section ends with “if this doesn’t work, page the on-call.”
The on-call rotation starts with two people. Weekly handoff. The handoff document lists what’s currently broken, what’s flaky, and what changed last week. We’ve never started a rotation without a handoff document and we never will.
Week 7: backups, secrets, and the things you only need once
Database backups have to exist, have to be restored at least once, and have to be tested in a recovery drill before launch. We do the drill in week seven, against a recent production snapshot, with a stopwatch. The first one always takes three times as long as anyone expected.
Secrets get moved out of .env files and into a real secret store: AWS Secrets Manager, Doppler, or Vault. The criterion is simple — can a new engineer onboard without anyone DM’ing them a credential? If the answer is no, the system isn’t safe.
Week 8: documentation and handover
The last week is writing things down. Every choice gets a one-page Architecture Decision Record. Every runbook gets reviewed by someone who didn’t write it. The on-call schedule lives in PagerDuty (or Opsgenie, or Better Stack), and the team can articulate, out loud, what to do when each of the five most likely incidents fires.
We leave the team with a maintenance load that’s measurable in hours per week, not days. The CTO sleeps. The next hire onboards in a day instead of a week. And nobody mentions Kubernetes.
What this costs
For a small-to-medium production system, the running cost lands somewhere between $400 and $1,200 per month for the infrastructure, depending on traffic and storage. Tooling costs roughly $200–$600 per month for the observability stack at this scale, less if the team self-hosts.
Our engagement runs eight weeks of senior time, plus a one-month retainer for the first on-call rotation. After that, the team owns it. The point of the ladder isn’t to keep us employed — it’s to give you something you can run yourself.