Yegor Bugayenko (yegor256) gives the most direct advice I've ever seen about hiring remote programmers, generally remote teams. The advice could be scaled down a bit for an individual developer. The general thrust is to keep things incremental: demand access to source at all times, one click build processes, regular independent code audits, change the team regularly so no one becomes essential to the process, demand a list of risks be updated regularly, etc., etc.
Yegor has direct and extensive responses to each of your points, and many more. Not that he is always correct, but he never avoids the questions you raise, and is happy to engage in discussions. Since he himself ran a development shop in Ukraine for many years, he is pulling back the curtain and sharing tips to stabilize a difficult process, especially for non-technical customers. He even has his money where his mouth is, with patents and a startup implementing many of the principles he lays out in a scalable system called Zerocracy[0].
And just as a counterpoint to your $10k customer needing to choose between things, there are hundreds and hundreds of customers who lose every penny of their $10k and start over from scratch. (That is what is in the podcast episode, if you have yet to listen.) By imposing the extra process and expense at the beginning, the customer can guarantee some forward progress toward their goal instead of trusting the dev shop to deliver everything by the end in a big bang delivery.
On the "one click build process", I recall once talking with a friend of mine who worked on a fairly large Java project back when Java was first developed. There was no build system that was associated with Java and for reasons that I don't quite understand the development team were very unhappy using proven solutions like make. So they had this very fragile set of scripts for building the application. After about 2 years (!!) of development, the startup ran out of cash and they were rather desperate to ship a product. It actually worked quite well. The only problem? Nobody could build the whole thing and make a single image! The company exceeded their runway before anyone could figure out how to ship. It's stupid, but it happens. Whenever I start a project I remember this and consider that that absolute top priority of any project is to be able to ship. You should do that first. (As an aside, it's pretty weird that your first story is often to ship nothing).
I think if you have a $10K project and you know that you are going to be really, really tight on resources, you don't skimp on the build process. Rather you back up and choose tools that are proven and reliable. If you can't get your 1 click (or equivalent) build process up an running in a day for a $10K project, then you have selected tools that are much too risky. That's my 2 cents, anyway.
Another advantage of a "one click" build process is that it documents, perfectly, the product. What lives where, maps to what and how, how each element is configured, etc. That "one click" is your way into the whole project.
If you have $10k dollar, you may have to choose between the one click build process and some features or documentation.
Regular audits and updating list of risks have a cost and affect the deadline.
Change the team regularly ? Do you know the cost of introducing anyone new even to the best made project ?
What if you are an individual ? What if you are a start up ? What if you are a small company or an NGO ?
I'm not saying those are not good to have.
But I would put much more simple and basic things prior that. Nobody has unlimited time and resources.