He recommends always hosting the systems on the client’s NAN (their account) so handoff is easy—you just give them the account and walk away. Hosting on your own account creates extra work like handoff documents and training, and while you lose some leverage, he prefers leading with value and avoids the reputational risk of seeming controlling.
You definitely don't need your client's bank account details; they only need a Google Cloud account. On a kickoff call, walk them through setting up Google Cloud, screen‑share if helpful, and coach them through the process without asking for card details. After they’re set up, take the Google Cloud client ID and secret and add them to your NAN. That’s the straightforward way to solve the immediate problem. However, honestly you shouldn’t have this problem at all—self‑hosting turns a simple automation logic task into a DevOps and coding burden (environment variables, webhooks, reverse proxies, etc.) that adds no real value for the client. A better approach is to use the cloud‑hosted version of OOTH (or similar), which is simple, always supported, avoids downtime, and lets NAN handle errors for you. The cost (e.g., $25–$60/month) is tiny compared to the value you deliver; if you’re not getting at least a 20× ROI on that spend, you probably shouldn’t be building the system for the client in the first place.
You don't really need to if I'm honest. I imagine you're probably using NAND, but I don't recommend you use self‑hosting if you're a noob to NAD and want to work with clients. I recommend you get the client‑cloud hosted offer.
Yes, the best option is to pay the default fee for a carefree experience with all the hassles. I'd love to see a video on this, as I was almost tempted to go self-hosting and learn the platform. I've tons of experience breakinging down barriers and obstacles of self-hosting and common apps affected by it, and how much more effort and time is needed to manage and maintain. Suffice to say, the reason I typically recommend cloud hosting everything is that you don't have to deal with deployment, DevOps, or additional environment variables and similar self-hosting concerns. As an automation specialist, believe it or not, your main point of value is not in your technical knowledge; it's in knowing just enough of the technicals to apply them to real business processes. Then you spend the rest of your time becoming a business person, a business expert. That's where the leverage lies with the alpha people who get really into self-hosting—they often lose the cart for the horse, spending so much time figuring out every little technical detail, spinning up Docker containers, getting environment variables right, and doing EngineX pass-through for webhook URLs. It's incredible how much time that takes. My recommendation is to focus on the things you actually get paid for—delivering value to your clients—not on designing the most optimal, technically and academically perfect solution.
I definitely go cloud‑hosted. It's just so much easier. With self‑hosting you run into DevOps and deployment concerns that are way above most people's pay grades. I often hit self‑hosted errors that can take hours to fix, and you also have to deal with Oauth setup—getting client IDs, client secrets, and configuring Google accounts, which is a massive pain. Cloud‑hosted avoids most of that and saves a lot of time.