Almost everything published on choosing a Kubernetes partner is written by firms who would like to be chosen, which shapes the questions. This is our attempt at the version that includes the awkward ones.
Ask what they have operated, not what they have built
Building a cluster is a weekend. Running one through two years of upgrades, a certificate expiry, a cloud provider incident and a security disclosure is a different discipline, and it is the one that determines what you inherit.
Ask directly: what did you operate, for how long, and what broke. A consultancy that has only ever delivered and handed over will produce something that works on the day it is delivered, and the operational cost of that will be yours to discover.
Ask about scale honestly, in both directions
Experience at very large scale is not automatically an advantage. Someone whose instinct comes from a hundred clusters may build you a platform sized for a problem you will not have for five years, and you will pay for that complexity every month.
Ask what they would not build for you. A partner who cannot name anything is selling a template.
The useful signal is whether they adjust. If the first conversation reaches for a service mesh and a developer portal before understanding your team size, you are getting a standard architecture rather than a considered one.
Establish who is actually doing the work
This is the single most common source of disappointment, and it is easy to check. Ask who will be on the engagement, whether the people in this meeting are those people, and what happens if they are moved.
Larger firms sell with senior architects and deliver with whoever is available. That is not dishonest, it is how the model works, but you should know which model you are buying.
UK-specific things worth asking about
If you are regulated, a partner who has worked under the same regimes will save you months of translation:
- Data residency, and whether they have kept workloads within UK or EU regions in a way that survived review.
- Whichever framework applies to you, whether that is FCA expectations, NHS data security standards, PCI DSS or Cyber Essentials.
- UK GDPR specifically, including how deletion requests are handled in a distributed system.
- Whether they have provided evidence to an auditor before, rather than only built to a standard.
Location matters less than it used to. Most of this work is remote, and a partner two hundred miles away who has run your compliance regime beats a local one who has not. Time zone and language matter more than postcode.
Answers that should concern you
A proposal that names tools before understanding your constraints. Reluctance to say what would be handed over and how you would run it without them. No opinion on what you should not do. An estimate with no range, which usually means the scope has not been thought about.
And any answer that treats a certification as evidence of operational experience. Certifications establish a floor of knowledge, which is genuinely useful, but they say nothing about whether someone has been on call for what they built.
The question we would ask
Tell me about something you built that did not work, and what you did about it. Anyone who has operated at any scale has one. An answer that is specific, unflattering and ends in a lesson is worth more than any case study, and an inability to produce one usually means the delivery-and-leave model.
