Last time I killed a SaaS idea because an API said Forge and OAuth2 apps could not reach the data. This time the API let me in and the review process was the wall.
Same check, different platform. I think the check generalises, so here it is with the second worked example.
The check
Before writing code I try to answer one question: can the architecture I actually intend to ship reach the data it needs — commercially, not just technically?
"Commercially" is doing the work in that sentence. It covers access, but it also covers what it costs to keep that access, forever, as one person.
The idea
A Google Workspace add-on that reads a user's existing Drive files and reports on them. The specifics don't matter — anything shaped like "point it at what you already have and it tells you something" lands in the same place.
To read files the user already owns, you need a Drive scope. So the checkable question becomes narrow: which scope, and what does that scope cost?
What the docs say
Google sorts OAuth scopes into three tiers — non-sensitive, sensitive, and restricted — and the tier decides your review path.
drive.file is non-sensitive. It grants access to
Create new Drive files, or modify existing files, that you open with an app or that the user shares with an app while using the Google Picker API or the app's file picker.
Read that carefully. It is scoped to files your app created, or that the user handed to your app one at a time through a picker. It is not "the user's Drive".
To reach the user's Drive, you need drive or drive.readonly. Both are restricted.
Restricted scopes require OAuth verification and a security assessment: CASA. And CASA is where the shape of the problem changes, because of one sentence:
All applications must be revalidated every year.
Assessments are performed by ADA-authorised labs. I could not find a self-assessment path for the tiers that apply here.
(Verified 2026-08-14, against developers.google.com/workspace/drive/api/guides/api-specific-auth and appdefensealliance.dev/casa/casa-tiering. If you are reading this later, check it again rather than trusting me — this is exactly the kind of thing a platform changes without telling anyone.)
Why that is fatal, and why it isn't about money
The obvious objection is that an audit is a cost, and costs are survivable. That framing is what fooled me for about twenty minutes.
It isn't a cost. It's a recurring fixed liability on someone else's schedule. Every year, for as long as the product exists, some number of days-to-weeks gets taken out of a one-person business by a process that produces no features, on dates you don't choose, where failure means your users lose access. There is no version of "I'll do it when I have time".
A funded team absorbs that. It is a line item and a person's job. Solo, it is the whole of some month, every year, forever.
The part that actually changed what I would build
Here is the consequence, and it is a product decision, not a compliance one:
Anything that processes files the user already has needs a restricted scope. Anything that creates new files can live on drive.file.
So the scope tier quietly sorts every Workspace add-on idea into two piles, before you write a line of code:
- Diagnose / analyse / audit what already exists → restricted → annual lab assessment
- Generate something new → non-sensitive → no verification required
I went in wanting to build the first kind. The docs told me that as one person I get to build the second kind. That is a better outcome than finding out during review, and it cost two hours.
One thing I have not verified verbatim: what drive.file does when a user picks a folder rather than a file. I read the scope definition as not extending to the folder's contents, but that is my inference from the wording, not a quoted line. If you have shipped an add-on and know the real behaviour, please correct me in the comments — that detail decides whether a whole category of product is viable on the free tier of review.
The general version
"There is an API" and "my architecture can commercially use that API" are different claims, and only the second one matters. The second claim has more ways to fail than access control:
- The app model you need is excluded (last post's Atlassian finding)
- The permission you need triggers a review you cannot sustain (this one)
- The access exists but the terms forbid the use you had in mind
All three are checkable in about two hours, before any code. None of them look like market questions, which is why "validate your idea" advice never mentions them, and why I nearly skipped this one because the idea felt obviously good.
I wrote up the full method as a memo — the seven checks I run, which passed, which failed, and the sources with dates.
Memo No. 001 — Jira Automation Conflict Preflight, verdict: kill
Disclosure so nobody feels ambushed: that page also sells the method as a $49 product. The memo itself is the complete worked example and costs nothing — if you only want the seven questions and the reasoning, they are all in there.
What is the permission or review requirement that killed something you were building?
