How do you decide whether a project actually needs Kubernetes, versus a simpler deployment approach?

This is fundamentally a judgment question, and the strongest answers walk through concrete signals rather than defaulting to "Kubernetes is the industry standard, so use it."

Signals that genuinely point toward Kubernetes

• Many independently-deployable, independently-scaling services — a handful of microservices with meaningfully different scaling/resource profiles benefit from Kubernetes's per-workload scheduling, autoscaling, and rollout mechanisms far more than a single monolith would.
• Need for self-healing across a fleet of machines — if you're already running enough compute that individual machine failures are a routine, expected occurrence (rather than a rare event), Kubernetes's automatic rescheduling is solving a real, recurring operational pain point.
• Sophisticated deployment patterns are actually needed — genuine canary/blue-green requirements, frequent rollbacks, progressive delivery — these map naturally onto Kubernetes-native or Kubernetes-ecosystem tooling (see the production operations topic).
• A platform serving many teams/applications — Kubernetes's consistent API and tooling (the same kubectl, the same RBAC model, the same manifests) across every application is a genuine multiplier once you have many teams that would otherwise each reinvent their own deployment tooling independently.
• Portability across cloud providers (or on-prem) genuinely matters — Kubernetes's abstraction over infrastructure specifics is valuable if avoiding cloud-provider lock-in, or supporting hybrid/multi-cloud, is a real organizational requirement, not just a hypothetical future concern.

Signals that point toward a simpler alternative

• A small number of services, modest scale — a single application, or a handful of tightly related services, often runs perfectly well (and far more simply) on a managed PaaS (Heroku, Render, AWS App Runner, Google Cloud Run) or a small number of VMs with basic automation.
• No dedicated platform/infrastructure expertise on the team — Kubernetes has a genuine, non-trivial learning curve and ongoing operational burden (even managed offerings require understanding RBAC, networking, resource management); a small team without that expertise pays a real tax adopting it prematurely.
• The team's actual bottleneck is elsewhere — if the real constraint is product development speed, not infrastructure scaling or reliability, the operational overhead of standing up and maintaining Kubernetes (even a managed cluster) can be a net drag rather than a net benefit at that stage.

The honest tradeoff to acknowledge

Kubernetes solves real, hard problems (scheduling, self-healing, service discovery, sophisticated rollouts) extremely well — but it solves them with genuine complexity: more concepts to learn (Pods, Services, RBAC, networking layers), more operational surface area (etcd health, node management, upgrade cadences even on managed offerings), and a real ongoing cost even when things are working smoothly. Adopting it because it's the "default" choice, without the underlying problems it solves actually being present yet, is a common, real mistake — over-engineering the deployment story before the application or team has grown into needing it.

A strong closing framing

"I'd want to understand: how many services, how much and how variable is the scale, does the team have or plan to build platform expertise, and are we anticipating genuinely needing rollout sophistication or multi-cloud portability soon. If the answer to most of these is 'not yet, and not clearly needed soon,' I'd lean toward a simpler managed platform and revisit Kubernetes once the actual pain points it solves start showing up for real." This kind of answer demonstrates judgment about fit, not just familiarity with the technology.