I Stopped Making a Google App for Every Script. Now I Have One, and It's Called Alessio's G-Suite

On 2 October my kids’ school script stopped at circular number 71. Silently. No alarm. No email. Nothing.

The script reads Nuvola, the electronic register used by my sons’ school, twice a day. It checks both my sons, finds the stuff I must actually do, puts it into my Google Calendar, and emails me. At least, this was the idea.

I found out myself on the 3rd that something was wrong. Then on the 4th it turned out the school had already published circulars 73, 76, and 77. I opened Claude Code and started digging. And there it was: the Google part had never actually been connected.

Gmail and Calendar were not working. The “to-do” email had never been sent. Not once. The script just skipped Google quietly when the credentials were missing. Beautiful.

The worst automation is the one that looks alive while quietly doing nothing.

Just silence. And silence, in automation, is where things go to die.

The Fix I Refused To Do

Claude’s first fix was technically correct. It gave me a step-by-step guide to create a Google Cloud project and OAuth app called nuvola-sync, just for this script.

Create the project. Configure consent screen. Enable Gmail. Enable Calendar. Create OAuth client. Download the secret. Store the credentials. You know the ritual. If you have touched Google Cloud Console even once, you know the smell.

I read the guide and stopped. Because next month another project of mine, a personal dashboard, needs to read my email. Then something else will need Drive. Then Contacts. Then some other little personal tool I build on a Sunday morning with coffee in one hand and false optimism in the other.

One app per script means doing this whole ritual again every time. And we’re back to square one.

The problem was not Nuvola anymore. The problem was my future self creating one Google app for every small script.

So I made a rule. Two apps. Forever. Never a third.

One is called “Alessio’s G-Suite” and it handles Gmail, Calendar, Drive, Contacts. The other is “Alessio’s G-SEO Suite” and it handles Search Console, Analytics, Tag Manager. That one gets its own article.

Both are owned by my company’s Google account, ISH Consulting. Both are billed to the company billing account. Not because this is some enterprise architecture masterpiece. Because I don’t want personal scripts, half-broken OAuth clients, and random projects spread around like dirty socks.

Why Google Cloud Makes This So Annoying

If you leave an OAuth app in “Testing” mode, Google kills the refresh token after 7 days. So your script works for a week. Then dies. Exactly the kind of silent failure I was trying to remove.

Then you discover “Internal” apps. No verification. No refresh token expiry. Nice. Except internal apps only exist for Google Workspace organisations. A plain @gmail.com account can’t be internal. So the only way out is “External” + “In production”.

And “In production” sounds public. It isn’t. The app is listed nowhere. It only works for accounts that click through its consent screen.

The price is the scary screen: “Google hasn’t verified this app.” Then you click Advanced → Go to… Like you are entering a cave.

There is also a cap of 100 users. I need two or three. Fine. It still allows the restricted scopes too: full Gmail, full Drive. No security assessment needed for your own use.

Then the Google Console does the Google Console thing. The “Publish app” button stays greyed out with the message: “you must complete your configuration on the Branding page.” Nothing tells you which field. Nothing.

We found it by trial: you need both a home page and a privacy policy link. And the domain as authorized domain. So the site got a privacy page.

A logo, on the other hand, forces verification. So no logo. Because apparently my app can read my full Gmail, but God forbid it has a small image.

Most of the complexity was not security. It was the console asking for things without saying what was missing.

Also: the client secret is shown once, in a dialog, after you create the client. Miss it, and enjoy your next little treasure hunt.

The Part Where Claude Drove Chrome

I only did two logins. One in my normal browser, for the gcloud command line, as the company account. One in the dedicated Chrome that Claude drives.

From the terminal, Claude created the two projects, linked them to the company billing account, deleted the leftover nuvola-sync project, and enabled 8 APIs. 4 per project.

Then came the console part. The part that has no API. Earlier in the session, the usual browser tool, an MCP, had died. So Claude wrote a script. Around 60 lines. It talked to Chrome directly over the DevTools protocol.

Navigate. Read the page text. Type into Angular form fields. Press Enter to turn an email into a chip. Tick the policy checkbox. Click Create. Publish. Confirm. When the client dialog showed the secret, it read it from the page and saved the credentials file itself. chmod 600. Outside every repo.

I watched it. I did not click anything in the console.

From the first project command at 10:18 to the second client saved at 10:30. 12 minutes.

Holy shit.

The funny part is that the code was easy once the browser stopped being my job.

And yes, this is the strange new line we are crossing. Not “AI writes a function.” Boring.

AI opens the terrible admin interface, finds the hidden fields, clicks the right buttons, reads the one-time secret, and stores it where it belongs. That is the part where I felt the difference.

What I Have Now

Now every repo uses one command:

node tools/google-access.mjs auth suite <email>

Once per mailbox. Then token or check.

From Node, it is one import:

accessToken('suite', email)

Adding a mailbox later? One consent. Nothing in Google Cloud. Adding a scope? Add it to the app and consent again. Never a new project.

The first check after consent was boring in the best possible way. Gmail reachable: 90,637 messages. 4 calendars. Drive: 63 GB used. 1,505 contacts.

Then the school script ran again that same morning. It picked up the 3 new circulars: 73, 76, 77. It found 3 things to do.

It put 1 event in my calendar: 13 October, parents’ meeting for the class representative election. And it sent me 1 email. The first email that system ever sent.

The value was not “a better Nuvola script.” The value was removing Google Cloud from the next small ideas.

That rule now lives in my global Claude instructions. Every repo uses these two apps. Never a third.

The Hidden Cost Of “Just One More Integration”

This is the thing we underestimate. Not the code. The code is usually fine.

Read an API. Store a token. Refresh it. Call Gmail. Put an event in Calendar. A product person looks at it and says: “small integration.” A developer looks at it and says: “yeah, maybe one evening.”

Then Google Cloud Console enters the room, and none of what follows feels like work that creates value. It feels like paying tax to the platform before you are allowed to build the thing you wanted.

Maybe this is the boring infrastructure nobody sees. But I know exactly what it buys me the next time I want to build a script at night because my kids’ school, my calendar, or my inbox did something stupid.

No new project. No console ritual. No square one.

How many half-configured Google projects do you have lying around?