In your vaule.yaml file you can add variables to enable services e.g. backupServiceEnabled: true then in a requirements.yaml file you can add conditions to your services e.g.

dependencies: - name: backup-service condition: backupServiceEnabled.enabled

In general in Kubernetes, if you submit some object that's identical to the object that's already there, nothing happens. For example, say you have a Deployment named all-services-bridge-service, and you submit an identical Deployment with the same name and same contents; the Kubernetes core controllers will look at the new Deployment, see that the existing Pods exactly match what is requested by the Deployment, and do nothing. When I say "submit" here I mean either kubectl apply or the equivalent work done by helm upgrade.

So say you have a Helm values file that looks like

backup-service:
  tag: 1.2.3
counter-service:
  tag: 1.4.0
bridge-service:
  tag: 3.2.1

where the templates copy .Values.tag into the Deployments' image: settings. Now, say you have a release of counter-service and change

counter-service:
  tag: 1.5.0

You can safely helm upgrade the whole thing. Yes, it will produce a new deployment spec for the other two services and submit them, but since the image tag (and presumably other details) are the same, there will be no net effect. Even if there are changes, the resulting rotation of Pods should be pretty routine.

If it's important to you to be able to only upgrade these sub-charts one at a time, you will need to promote them to top-level charts. (In other contexts I've found a chart-of-charts managing multiple microservices to not work especially well; if A requires Redis and B requires Redis, for example, a combined umbrella chart that installs both A and B will only install one Redis and share it, which you probably don't want.)