DEV Community: Seiya Sato

The scope you pick decides whether you can ship alone

Seiya Sato — Fri, 14 Aug 2026 08:01:25 +0000

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?

The API exists. That doesn't mean you can build on it.

Seiya Sato — Thu, 13 Aug 2026 13:53:42 +0000

I killed a SaaS idea last week after about two hours of research. The thing that killed it is one sentence in Atlassian's API documentation, and the general shape of that failure seems more useful than the idea was.

The idea

Jira automation rules fail in ways that are hard to see before they hurt: two rules firing on the same transition and racing, a rule editing an issue another rule just deleted, circular triggers, behaviour that silently depends on rule ordering. Teams hit this and debug it by hand, after the fact.

A static analyzer for automation rules looked tractable. Rules are structured data rather than free text, so the analysis is deterministic — no model guessing at intent. Atlassian has a marketplace, so distribution is at least partly solved. I have built smaller things on thinner reasoning than that.

The check

Before writing any code I try to answer one question: can the architecture I actually intend to ship reach the data it needs — commercially, not just technically?

For a Marketplace app, "install it and it works" means Forge, or an OAuth2 integration. That is the entire product experience. So the question becomes narrow and checkable: can a Forge app read automation rule definitions?

Every endpoint in the Automation REST API's rule-management group carries the same line:

Forge and OAuth2 apps cannot access this REST resource.

Eight endpoints, same sentence on each. (Verified 2026-08-13. If you are reading this later, check it again rather than trusting me — this is exactly the kind of fact a vendor changes without telling anyone.)

Why that is fatal rather than annoying

There are workarounds. A user can export rules as JSON and upload them. An API token scoped to a user's own account can read them. A local CLI could do it on their machine.

Each of those is technically fine and commercially different. They replace "install it from the marketplace and see your problems" with "read these setup instructions, produce a file, then upload it". For a low-touch self-serve product sold to teams who are already annoyed, that is not a smaller version of the product. It is a different product, with worse economics and worse conversion at exactly the moment a new user decides whether to care.

The problem is real. The analyzer is buildable. The business I wanted is not available.

The general form

"There is an API" and "my architecture can commercially use that API" are different claims, and only the second one decides whether you have a product.

Worth checking before you write code, roughly in the order these things kill projects:

Is commercial use permitted at all, or is the API for internal and personal use?
Does your intended auth model — Forge, OAuth2, API token, service account — reach the exact objects you need? Not the API in general. The specific resource.
Is there a partner agreement, certification, or security review standing between you and production?
Do the rate limits fit your access pattern, or do they fit a dashboard that refreshes once an hour?
If the platform absorbs this capability in 12 months, what is left of your product?

None of this is exotic, and all of it is in public documentation. It just requires reading the docs for the thing that would kill you rather than the docs for the thing you want to build.

Why I bother

AI-assisted coding made building cheap enough that building is no longer the expensive mistake. Choosing what to build is. A weekend prototype costs a weekend; the wrong choice costs a month, and you find out at the end of it.

So I run a fixed set of checks before starting. This one — commercial API reality — has killed more of my ideas than any other, and it is the one that generic "validate your idea" advice never mentions, because it does not look like a market question. It looks like a documentation question, right up until it ends the project.

I wrote the whole thing up 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

What is the check you wish you had run before building something?