If you’re showing the client the site on your machine, you could use the approach I mentioned of adding a temporary entry to your /etc/hosts. But more likely, you want enable the client to visit the site on their own devices and you don’t expect them to mess with /etc/hosts.
There could be many approaches, but if I had to do it right now, I’d set up DNS to point staging.mydomain.com to a different IP, for a new staging droplet (e.g., IP in hosts/staging). I’d ask clients to visit staging.mydomain.com to preview the site (and to preview ongoing changes after the site is launched). This staging site shouldn’t be indexed by search engines if you’re using bedrock (here’s why), but you may still want to put the staging site behind basic auth like in “Bedrock site protect” here.
Of course, when you’re ready to launch, add a DNS entry to point mydomain.com to your original IP (e.g., IP in hosts/production). You end up with staging and production on different droplets, different IPs, which gives you good flexibility in development. You can do anything you want to your staging server without affecting your production server.