What I wish I'd known before touching an OAuth restricted scope — shelving a personal app over CASA's $540/year

About this post
Co-edited with Claude (Anthropic).

Summary

I built an app (bonsai) to read and write Markdown from Google Drive on a phone, and pushed it all the way to Play Store and OAuth submission

Implementation was fast alongside AI. But the real work of shipping was non-code — the long back-and-forth of store review and OAuth verification

The deciding blow was an email from Google: apps using a restricted scope (full drive access) must pass a yearly security assessment called ADA-CASA AL1, at $540/year even at the cheapest lab. Not worth it for a hobby app, so I retreated

The core lesson: OAuth scopes come in tiers — non-sensitive / sensitive / restricted — and the non-sensitive drive.file needs no CASA and no demo video. I had unknowingly picked the heaviest one, drive

I shelved it, but the editor I built lives on: ported into capture apps where drive.file is enough. Retreat is a design decision too

“With AI, even a solo dev can build an app.” Half of that turned out to be true. The other half — actually shipping what you built — was a long, non-code road that has nothing to do with code. And at the end of it, Google handed me something close to a yearly invoice, and I folded the app.

This is a record of building a Google Drive Markdown editor (bonsai), trying to publish it, and retreating over an OAuth restricted scope and a security assessment called CASA with a yearly cost. I’ll write honestly about what technically got stuck and what I should have known first — including the parts where I was simply ignorant. If it helps someone before they reach for the same scope, the detour was worth it.

What I was trying to build#

A bit of background first. This was my second personal app. The first was a vertical-writing browser called tanzaku that reformats horizontally-written Japanese sites into vertical text — and it made it to the Play Store just fine. tanzaku touches no heavy permissions like Drive, so it didn’t get badly stuck on the way to release. bonsai was the second one, and this time I was stepping into Drive integration.

bonsai is a viewer and editor for reading and writing, on a phone, the Markdown scattered across your own Google Drive.

The motivation was simple: the Drive app and Google Docs don’t let you read or write md comfortably on a phone. Docs drags along its Word structure, so it fits poorly with plain Markdown. “I want to grow the md I keep in my own Drive, right from my phone” was the starting point.

Its place in the picture: an app that photographs handwritten notes and turns them into md (itadori) makes the seed, you turn that into knowledge, and bonsai is where you grow it. The stack is React Native + Expo, auth via Google OAuth, storage being Google Drive itself. No server — the device calls the Drive API directly.

The implementation itself came a long way: folder browser, list / tree views, md preview, an editor with auto-save and conflict detection, English/Japanese i18n, onboarding, even the billing groundwork. It really did reach the point of working as an app.

The gate far beyond “it works”#

With AI, implementation is fast. But the real body of work before release wasn’t code. Here’s what I did alongside it.

Google Play side

Distribution to Internal Testing, data safety declaration, content rating, target age
Personal accounts created after 2023-11 have a “production unlock” rule: you can’t publish to production until you complete Closed Testing with 12 testers who stay opted in for 14 days. You have to start from recruiting testers (r/TestersCommunity on Reddit, etc.)

OAuth verification (Google Cloud) side — the real topic

Production configuration of the OAuth consent screen, ownership verification of authorized domains
An English justification for each scope: why this permission is needed
Getting the privacy policy in order — and the homepage and PP must be at different URLs (identical URLs get bounced)
A demo video: unlisted on YouTube, in English, showing the app name on the consent screen and a full run of actually using the scope (create / edit / auto-save / delete into the Drive trash). I recorded it by driving a physical device via adb and burned in subtitles. That alone was a whole job
Rejections and email round-trips: “homepage and PP are identical,” “reviewers can’t sign in and test,” “the app can’t be downloaded (Item not found)”… each time I traced the cause and replied in English. I created a dedicated review Google account, set up an internal-app-sharing link, and it went on and on

The biggest lesson right here: “AI can build an app” and “you can ship an app” are entirely different. Before release sits a long non-code road of infrastructure setup, store review, and OAuth review. If anything, that was the real thing.

The deciding blow: CASA’s yearly fee#

The timing was, of all things, the worst. After round-tripping through OAuth rejections, and after completing on the store side the 12-testers × 14-days closed test required to unlock production — I was one step from publishing. That’s when the email arrived on 2026-07-16 from Google’s Third Party Data Safety Team, and it was the deciding blow.

In short: apps using a restricted scope (here, full Google Drive access drive) must pass a security assessment called ADA-CASA AL1 every year.

Here’s what I found when I looked into it¹:

The old free self-scan is gone; you must go through an accredited lab (TAC Security and others)
The cost is ~$540/year even at the cheapest, TAC Security. And it renews every 12 months
The assessment takes 2–6 weeks

A recurring $540 a year, for a hobby app with modest revenue. That’s where I got cold-headed. “This doesn’t add up.” Coming right after I’d recruited testers and completed the full 14 days of closed testing, it honestly stung quite a bit. Because AI let me build it so fast, the weight of that yearly fee stood out all the more.

Looking back: where I was ignorant#

Things I only understood after trying, that would have changed the design had I known them first.

First, OAuth scopes come in tiers: non-sensitive / sensitive / restricted¹. Restricted review is an order of magnitude heavier (CASA, demo video, use-case writeups, in-app testing…). Knowing none of this, I had picked the heaviest one, drive (full access).

Second, there was a non-sensitive scope option: drive.file. With it, neither CASA nor a demo video is required. Had I designed with this from the start, most of the review hell wouldn’t have happened.

But drive.file has a hard constraint. Access is determined not by a folder’s location but by each file’s “origin”: you can only touch files the app created, or files the user explicitly picked via the Picker¹. Selecting a folder doesn’t reveal its contents, and moving an existing md made elsewhere into bonsai’s folder still won’t show it. So bonsai’s core experience — freely browsing all of Drive and opening any md — could structurally only be done with a restricted scope. That’s the essence of the checkmate here.

Third, the self-judgment “we’re serverless, so we’re out of CASA’s scope” doesn’t hold. I had in fact prepared an architecture diagram showing no server, arguing “this shouldn’t meet CASA’s trigger condition.” But for a restricted scope it’s mandatory across the board — it’s decided by the scope tier, not by trigger conditions.

To sum up: I should have chosen the permission scope minimally at the very first step of design. Realizing later that “restricted actually requires a paid yearly review” means rebuilding the whole experience you already crafted.

The other option: escaping to drive.file#

Before deciding to retreat, I did once consider — and even start building — a migration to drive.file to avoid CASA.

The idea was a “bonsai-home folder model.” Stop browsing all of My Drive; after sign-in, create a dedicated root folder named bonsai that’s visible to the user, and manage only inside it. Everything under an app-created folder is app-owned, so with drive.file the list / tree, create, move, delete, edit, and auto-save all still work. You give up scanning all of Drive, but within the bonsai subtree it’s business as usual¹.

This drops the entire restricted review — CASA, demo video, use-case writeup, in-app testing. It was a technically viable escape route.

One constraint remains: existing md made elsewhere isn’t visible automatically. Only files the user picks one by one via the Picker can be brought in. (An app-private hidden folder, drive.appdata, is invisible to the user, which clashes with the “live inside Drive” idea, so I ruled it out.) It’s a step back from the original experience of “open existing md in Drive right where it sits.”

Retreat — but keep what I built#

With the escape route designed and ready, I finally took an honest look at how I actually use things.

Wanting to edit a note generated on my phone, right there → yes
Organizing the cloud / browsing files on my phone → almost never

So the need for a dedicated view-and-organize “growing” app was, for me, thin. In that case the editing feature belongs inside the photograph/record apps (itadori / komadori) as “fix it right after you make it.” Those only ever write their own output, so drive.file is enough and CASA is irrelevant.

So I shelved bonsai (dormant). I won’t delete the code. The editor, preview, and auto-save I built get ported straight into the capture apps, which run on the same React Native + Expo. Retreat isn’t reducing things to zero; it’s folding by reusing the parts you built elsewhere in the ecosystem — a design decision.

As for the OAuth verification submission itself, I withdrew it per the “reply to cancel” in Google’s email, moved the consent screen back to Testing, and removed the restricted scope from the code too.

Wrap-up — the 3 things I wish I’d known first#

For solo devs heading the same way, just three things from someone who took the detour.

OAuth scopes come in tiers — non-sensitive / sensitive / restricted. This tier alone changes how heavy the review is, by an order of magnitude
Choose a restricted scope and you’re saddled with CASA, a paid yearly security assessment (~$540/year even at the cheapest), every year. “We’re serverless, so we’re exempt” doesn’t fly
So pick permissions minimally at the first move. If drive.file gets the job done instead of drive, take it without hesitation. Realize it late, and you rebuild the whole crafted experience

Now that building is faster with AI, the place you get stuck has moved outside the code. If this article shows even a little of the gap between “can build” and “can ship” ahead of time, I’m glad.

One last thing. I folded bonsai, but I have no intention of quitting app development itself. I’ve got one app in closed testing right now, and a few more in the works in parallel. Applying this lesson to the very first move of scope design, I’ll simply push those forward. If one or two retreats were enough to stop me, indie dev wouldn’t last. Hope to see you again at the next release.

References#

Google Workspace — Choose Google Drive API scopes (the difference between drive and drive.file, and the scope tiers) https://developers.google.com/workspace/drive/api/guides/api-specific-auth