How to choose a DevOps company: what good work looks like.

Most DevOps work is invisible until something breaks. Every DevOps company promises automation, reliability, and speed, so the useful question is how to tell them apart before you give one access to production.

This is how we would evaluate a DevOps company if we were the buyer. We are one ourselves, based in Yerevan, Armenia, and working with engineering teams worldwide, and every question here is fair to ask of us too.

1. Ask to see how changes reach production

The fastest way to judge a DevOps team is to watch one change travel from a commit to production. Ask them to walk you through a real pipeline, anonymized if needed:

• Where the infrastructure is defined (Terraform, Terragrunt, Pulumi) and how a change to it is reviewed.
• How an application release is built, tested, scanned, and promoted between environments.
• How a bad release is rolled back, and how long that takes.
• Who can change production, and how that access is granted and removed.

A good answer looks boring and specific: a pull request, a plan, a review, an automated apply, and a rollback that is just another change in Git. A vague answer, or one that involves someone logging in to fix things by hand, tells you how your platform will be run.

2. Check that everything is code

“Infrastructure as code” is on every DevOps website. Check how far it goes:

• Cloud resources: accounts, networks, databases, and permissions in Terraform or Terragrunt, not created in the console.
• Kubernetes: clusters and the add-ons on them (ingress, autoscaling, secrets, monitoring) defined in code, with workloads deployed through GitOps tools such as Argo CD or Flux CD.
• Pipelines and policies: CI/CD definitions, security scans, and admission policies in the repository, reviewed like any other code.

If a company cannot rebuild your environment from its repositories, it has not really automated it.

3. Ask how they keep systems running

DevOps does not end at deployment. Ask what happens at 3 a.m.:

• What is monitored, which alerts go to which team, and how alert noise is kept down.
• Whether they write runbooks for the incidents they expect.
• How on-call works, which hours are covered, and what an incident outside those hours costs.
• What they review after an incident, and whether those reviews lead to changes.

4. Match the engagement model to the work

Most DevOps companies offer some mix of these:

• Embedded engineers (staff augmentation): they join your team, your tools, and your backlog. Best when the work is ongoing and your team owns the roadmap.
• A fixed-scope project: a migration, a Kubernetes platform, or a delivery pipeline with clear milestones. Best when the outcome is well defined.
• Managed operations: a retainer for someone else to run production. Best when nobody on your side can.

Be wary of a company that recommends the same model for every problem. And for any model, ask how knowledge comes back to your team: documentation, pairing, and a handover plan from the first month.

5. Look for these warning signs

• Infrastructure created in their cloud accounts or tools rather than yours.
• One senior engineer who knows everything, with nobody to cover their holidays.
• No written rollback plan for migrations.
• Security treated as a later phase instead of part of every change.
• Case studies made only of adjectives, with no architecture or numbers.

6. Ask for evidence

Ask for two or three case studies close to your problem, with the architecture, the decisions, and what changed afterwards. Ask to talk to the engineer who would actually do the work, not only the account manager. Reviews on Clutch or similar sites, and AWS, Azure, or Kubernetes certifications you can verify, help separate claims from track record.

The short version

Choose a DevOps company that can show you a real pipeline, keeps everything as code in your accounts, has a clear answer for incidents, offers the engagement model your problem needs, and plans the handover from day one.

If you are comparing DevOps companies, here is how we work with engineering teams: DevOps Staff Augmentation and Kubernetes & Infrastructure Scaling. For examples, see from one test cycle a week to ten a day and a legacy monolith moved to an EKS delivery platform.