What we build with it
A service running on Kubernetes is not one thing — it is a deployment, a service, an ingress, an autoscaler, and a set of secrets that all have to agree with each other. Helm makes that collection a single chart with values, so an environment is a values file rather than a directory of near-identical manifests that drift apart.
The practical benefit is that a release becomes one reviewable, versioned object. You can see what changed between two deploys, promote the same chart from staging to production with different values, and roll the whole thing back as a unit when a deploy goes wrong — rather than undoing five resources by hand while the site is down.
Where it fits
This site ships this way. Its chart carries the deployment, ingress, horizontal pod autoscaler, image-pull secrets and application secrets, and CI applies it after building and pushing the container image.
When we recommend it
Once you have more than one environment or more than one service. That is the point where hand-maintained manifests start diverging and nobody is sure which cluster matches which file.
For a single service in a single environment, plain manifests in Git are easier to read and one less templating language to debug. Helm's templating is genuinely awkward — whitespace-sensitive YAML generated by Go templates — so it should be earning something. When it is just one deployment, it is not.