Summary
[!note] 📚 Pilotflow Series: Building a Gmail Addon
- The $50,000 Lie That Almost Killed My Gmail Addon ← you are here
- Gmail OAuth Scope Tiers Decoded — June 15
- Pre-Development Codebase Analysis — June 22
- Legal Documents for Gmail Addons — June 29
Let me tell you about the moment I almost shut down a project before writing a single line of code.
I was planning Pilotflow, a Gmail addon that helps users reclaim control of their inbox. The core feature involved reading email threads — understanding what was there so the user could act on them intelligently. While researching Google Workspace Marketplace requirements, I found a forum post, then another, then a Stack Overflow answer, all pointing to the same conclusion: a Gmail addon that reads email requires CASA Tier 2 certification, which costs $50,000 to $75,000.
Fifty thousand dollars. For a solo developer. To certify a free tool before making a single dollar.
I nearly closed my laptop and moved on.
The Myth That Circulates in Developer Communities
The figure appears in dozens of places: blog posts from 2022, developer forum threads, indie hacker discussions. And it’s not entirely wrong — that price is real for CASA Tier 2 certification under certain assessors. But it describes one end of a spectrum, not the whole picture.
Takeaway: The $50,000 CASA certification figure is real — but it’s the ceiling, not the floor. The actual cost depends on which assessment path you choose.
What I found after deeper research changed everything.
Google’s security program for Workspace Marketplace applications has different tiers based on the sensitivity of the OAuth scopes your addon requests. CASA (Cloud Application Security Assessment) is required for restricted scopes — the ones with the most invasive access. But here’s what the forum posts always omit: CASA doesn’t have a single price. It has multiple assessment paths, and some of those paths cost a small fraction of what the alarming numbers suggest.
What CASA Actually Is (and Who Does It)
CASA stands for Cloud Application Security Assessment. It’s Google’s framework for evaluating whether an application requesting restricted OAuth scopes handles user data responsibly. Google doesn’t run the assessments — they authorize third-party security firms called CASA TAPs (Third-party Assessment Providers) to conduct them.
The assessments follow the OWASP Application Security Verification Standard. Your application is tested against a standard set of security requirements, and if it passes, you receive a certification letter that allows you to publish to the Google Workspace Marketplace with restricted scopes.
The expensive assessments are the most thorough ones — they include penetration testing, manual code review, and extended vulnerability analysis. But not every addon needs the full-service option. What most forum posts describe is the premium tier, without mentioning that alternative paths exist.
The Real Numbers I Found
After speaking with two CASA TAPs directly and reading through Google’s official program documentation, the price range I found was very different from the circulating myth:
| Assessment path | Approximate cost | What it covers |
|---|---|---|
| Self-assessment (with TAP review) | $540–$900 | OWASP ASVS checklist, TAP validates your work |
| Standard TAP assessment | $900–$1,800/year | TAP reviews app, no full pentest |
| Full penetration testing assessment | $15,000–$75,000+ | Complete manual testing, code audit |
[!note] The key insight The $50,000–$75,000 numbers describe full penetration testing. A standard TAP assessment for a modest SaaS application sits between $540 and $1,800 per year — a completely different category.
For Pilotflow at MVP stage, the relevant assessment is the standard TAP path. Not because I’m cutting corners, but because a standard security assessment is appropriate proportionally: it matches the risk profile of an indie addon versus an enterprise integration handling financial data.
But Here’s the Twist That Changed My Design
Finding out the real cost was a relief — but it didn’t end the analysis. It opened a more interesting question: do I actually need restricted scopes at all?
The scope I was planning to use was gmail.readonly, which grants full read access to the user’s entire inbox. That scope is restricted under Google’s classification, which is why it triggers the CASA requirement.
But I wasn’t building an inbox analytics platform. I was building a tool that helps users take action on specific email threads — the ones they’re currently looking at. And Google provides a different scope for exactly that use case: gmail.addons.current.message.readonly.
That scope is classified as sensitive, not restricted. It passes OAuth verification (a free process that takes 4–6 weeks) instead of CASA certification. The difference:
gmail.readonly→ reads the entire inbox → restricted → CASA certification requiredgmail.addons.current.message.readonly→ reads the currently open message → sensitive → OAuth verification only
The feature I wanted (help users act on email threads) could be built with the sensitive scope. What I didn’t need was background batch access to the full inbox. That was a capability I’d imagined having, not one the actual user workflow required.
Takeaway: Before budgeting for a restricted scope, ask whether a less-invasive scope delivers the same user experience. In Pilotflow’s case, it did — and it avoided the certification requirement entirely for the MVP.
The Decision That Saved the Project
The choice I made was to redesign Pilotflow around the current-message context rather than full inbox access. This meant:
- The MVP works within the currently open Gmail thread
- Users who want batch processing can invoke it on-demand (triggering context explicitly)
- No background inbox access — no restricted scope — no CASA certification for launch
The Notiwise project, which I’d built before Pilotflow, had already made a similar decision. When building a Calendar notification addon, the team discovered that gmail.addons.current.message.readonly would trigger CASA requirements while calendar.addons.current.event.read would not. The feature was redesigned accordingly, preserving the user value while eliminating the certification burden.
Pattern recognized. Principle applied.
[!info] When this applies Any time you’re designing OAuth scopes for a Google Workspace addon, start with the least-invasive scope that delivers your core user value. Expand scope only when a specific user workflow genuinely requires it — not because “more access is more flexible.”
What I’d Tell Someone Starting This Research
If you’re building a Gmail addon and you’ve encountered the $50,000 number:
- Check the scope classification first. Google’s OAuth scope documentation classifies every Gmail scope as public, sensitive, or restricted. Only restricted scopes require CASA.
- Design for the minimum viable scope. Identify the exact user workflow your feature enables, then find the most limited scope that covers it.
- If restricted is unavoidable, get actual quotes. Contact two or three CASA TAPs. The range is wider than the forum posts suggest, and the self-assessment path may be viable.
- Factor certification into your revenue model. If $900–$1,800/year is the cost, you need roughly $75–$150/month in revenue just to cover it. Plan accordingly before building.
The $50,000 myth nearly cost me a project I believed in. The actual cost, after proper research, was a non-issue for the MVP I was designing. But I only got there by questioning the number I’d read, not accepting it.
The next post in this series covers Gmail OAuth scope tiers in detail — the three-tier classification system and how scope choice affects both certification requirements and the user trust conversation during installation.
