How do you handle client credentials and passwords for complex authentication processes?
I'll do what's called a kickoff call where I get them together with me for a 30 to 45 minute period. I'll guide them through signing up for all the software platforms I want them to use. Typically I have three or four software platforms they need to sign up for. Most of the time, if we're doing something email-related, I'll have them sign up for a new Google Workspace profile. If they've never used a no-code platform, I'll make them sign up using my affiliate code—often something like PandaDoc. So I pretty much define sign‑up procedures for this: I send them all the links in the chat, they click the buttons, create the account, and then I have them do it with email and password so I can get it immediately and verify sign‑in right there. The issue with two‑factor authentication for most services is that people sign up using Google, which forces them through Google’s TFA system—a pain. If you get username‑password credentials, just add them to a password manager like 1Password, LastPass, or Dashlane; that eliminates a large portion of that issue. For the Google stuff, I typically log in using a software platform called Multi‑Login (multilogin). It’s great because you basically have to store the exact same credentials. Essentially this lets you set up dedicated browser profiles using residential and data‑center proxies so you can consistently log in with a static IP—the same IP address every time—minimizing the number of re‑authentications you need. Yeah, I use this for Google stuff from time to time; I don’t always use it, but that’s how I solve that problem. Hope that makes sense. If you guys have any more questions, feel free to drop them in the daily updates channel. Obviously this incentivizes my channel to grow because I get more engagement, and I can answer questions I get on this channel for the foreseeable future until it becomes unreasonable to do so.
It depends on what you actually need. In some cases you need to pretend to be the client — for example if you're sending emails as them, from their domain, you need their Gmail credentials (or API creds), full stop. You'll need their username and password, or at least a service account with equivalent access, and in that case you really do need to be handed their credentials. But a lot of the time you don't need to impersonate them at all — you only need Google Workspace access. If all you need is something like Sheets or Drive, have the client create you a new account on their own domain (e.g. yourname@theirdomain.com) so you have your own login rather than theirs. Then, when you create an asset — a Sheet, a Drive file, whatever — Google Workspace lets you share it domain-wide instead of restricting it to just you: on the file's share settings, instead of "anyone with the link," you add the domain itself as a group, set the access level (viewer/commenter/writer), and now everyone at that domain — including the client — automatically has access to anything you create, no individual re-sharing needed. Most integration platforms' Google modules (Sheets, Drive, etc.) support creating that kind of share link directly. So the short version: only ask for their actual Gmail/email credentials when you genuinely need to send or receive email as them, or need a webhook listening on their inbox — for everything else, a domain account plus domain-wide sharing gets the job done without ever touching their real login. And yes, Google's 2FA is genuinely one of the more annoying parts of this to deal with.
Sure. When a new client signs a contract and the invoice is paid, the first step is a kickoff call. In that call you thank them, clarify the problem you’ll solve, reiterate the value you’re delivering, and cover timelines, communication channels, account sign‑ups, and any two‑factor‑authentication requirements. You walk them through signing up for every platform you’ll use, making sure all 2FA is set up, and you aim to have every account, email, and password ready by the end of the call—ideally stored in a password manager like 1Password, LastPass or Dashlane. Then you invite the client to your communication hub (Slack, email, WhatsApp, etc.) and establish a cadence for updates, such as a brief status every couple of days. From there you proceed with the automation build. The client pays for everything: the automation platform (Make.com), any niche tools you use (Naden, PandaDo, Instantly, Mailfinder, ClickUp, Slack, Apollo/Amplify, etc.). Because you have affiliate partnerships with most of these services, you include your referral links, which typically give you a 3‑5 % margin, providing a small side‑income that continues even after the project is handed off.
We actually tried separate Chrome profiles per client — it works until you hit about 10 profiles, since Google doesn't easily allow more than that. You could also use something like a Multilogin instance to store credentials with longer-lasting cookies and residential/Bright Data proxies, giving you a fixed IP so you get logged out less (especially useful for accounts with 2FA). But honestly, I don't do any of that — I just use my own browser profile and manage everything with 1Password, which solves both the multiple-logins problem and general credential coordination. On handoff: since everything is built directly in the client's own accounts, there's no major handoff needed — I just send an email with a 20-minute SOP video plus a written Google Doc walking through the whole system, including how to maintain and upgrade it themselves, so they're covered even if we stop working together down the line.
He mentions he already made a dedicated video on maintaining the best 2FA procedure; look up Nick SAR how to manage an automation project. He explains that 2FA is annoying because you work with many platforms and need to glue them together. His strategy: start with a kickoff call, get the client to sign up using email and password (avoid Google/Facebook/GitHub to reduce 2FA), store credentials in a password manager (he uses OnePass), verify login during the call, frontload 2FA to get it out of the way, then for remaining 2FA (Google/Microsoft) ask the client to send the code directly, use an anti‑detect/multi‑login browser to store fingerprints and cut 2FA frequency to once a month or every two weeks, set a defined Slack availability window (e.g., 12‑2 PM PT) so you can respond quickly to code requests, and offer free maintenance on retainer builds.