How do you connect Google accounts to AnyTrack for customers, given the need to use Cloud Console and set up authentication? Should I create a new Gmail account for them or set it up on a video call?
I recommend that if you're self‑hosting AnyTrack, you actually shouldn't self‑host because the authentication steps become a pain. Most of the Google Cloud Console work you’re doing manually can be avoided by using the cloud‑hosted version, which provides a one‑click OAuth connection. You simply click “Connect with Google” and it signs in for you. If you do need to handle the Cloud Console steps, schedule a kickoff call with the client after you receive payment. During the call walk them through the process, have them share their credentials, and complete any two‑factor authentication live. Doing it live ensures that even if the OAuth token or 2FA expires, the integration remains in AnyTrack. By the end of the call you should have everything set up so you can start the client project without having to ask for additional access later, which keeps the process professional.
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.
I use make.com for the vast majority of my clients; it’s simple—just connect the account, click a button, and you’re done. For Google Calendar specifically, you don’t need to go through the full process of connecting a calendar to see events. If your goal is just to view events on a calendar, you can share that calendar with another calendar in the same organization, and the other calendar will see all events (and sometimes edit them) without needing the client’s Google Calendar. Instead, you can share your own Google Calendar, handling all the Google Cloud setup yourself. If that doesn’t work for your app, note that self‑hosted n8n will encounter more issues than cloud‑hosted n8n, requiring more frequent Google Cloud account handling. Cloud‑hosted n8n has built‑in direct OAuth integrations, making it easier (though slightly more costly). Overall, I think your mobile app idea is awesome and could be very valuable; just consider whether you can realistically invest the time and energy without immediate return, as SaaS apps often require that, whereas a service business lets you earn while you build, then later productize the solution.
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.
We cover this in Maker School, but here's a high‑level overview: if your cloud skill needs API X, you need access to API X. When building cloud workflows, you often create another workflow that extracts the specific platforms of interest, and that's what you require from the client. You don't need to do this up front or at the end—you can't build a system and then declare it ready to go live, because the whole thing is assembled with natural language in 30 seconds. Without a live version you can't test, which is the top reason developers are hated ('it worked fine over here'). Once you have API keys, things change, so allow some time. Get everything up front. Preferably use username/email and password; avoid OAuth Google sign‑in because it triggers constant 2FA requests from the original account owner. It's kind of annoying.