The $1,000 Annual Gatekeeper Tax: How Google Stifles Bootstrapped Email Innovation
I have been building Mitsa Mail, an independent, sovereign email client designed to give users a fast, private, and intelligent workspace for their communication.
Like most email client developers, my initial goal was straightforward: let users connect their existing Gmail account via Google OAuth, sync their messages into Mitsa, and send and receive mail.
To do that, an app needs two scopes:
https://www.googleapis.com/auth/gmail.readonlyhttps://www.googleapis.com/auth/gmail.send
Because gmail.readonly can view message contents, Google categorizes it as a Restricted Scope. This triggered Google's developer verification process, which led directly into an unexpected roadblock: the Cloud Application Security Assessment (CASA).
The Paywall: CASA AL1
Google informed me that before my OAuth app could be approved for public use, I was required to complete an Assurance Level 1 (AL1) CASA assessment under the App Defense Alliance framework.
AL1 is fundamentally a verified self-attestation. The developer fills out a questionnaire based on the OWASP ASVS standard and provides artifacts from automated vulnerability scans (such as OWASP ZAP).
The catch is that Google does not permit you to submit this directly to them. You are required to submit your documentation to an approved third-party security lab, which reviews the questionnaire and issues a Letter of Validation (LoV).
The labs charge for this review. The typical price is anywhere from $650 to $3,000 every single year.
For a venture-backed company with an enterprise security budget, $700 is a rounding error. For a solo engineer bootstrapping a product with zero revenue, it is a hard stop.
The Exchange
I wrote back to the Google verification team:
"This is unacceptable. This is a bootstrapped startup I don't have $675 just to connect to Google Mail service.
This is your way to discourage Startup and create entry barriers so that competition can't flourish. If this assessment is your requirement you pay for it, my application in fully compliant and I am ready for audit.
Your creation of entry barrier by imposing unreasonable demands on bootstrapped startups will meet with full public disclosure of your policies to public and Government authorities all across."
Google’s Trust & Safety team replied:
"Given the sensitivity of the user data that you will be accessing and the responsibility we have to maintain trust with users that their data is securely handled, we require apps to demonstrate that they can handle such data securely. We’re sympathetic to your concern, and have done our best to minimize the impact by negotiating discounted rates with one of the independent assessors (TAC Security) to keep the cost below $1000. As we’ve selected an industry leading assessor, the Letter of Validation that your app will receive can be used for other certifications or customer engagements where a security assessment is needed."
Notice the framing: Google considers it a concession that they negotiated with a private security vendor (TAC Security) to keep the fee "below $1,000."
I sent this reply:
"Your responsibility ends when user gives express permission to Mitsa Mail to access her account. This is contrary to the basic principal of Individual freedom enshrined in most of the constitutions of countries.
I will expose you and fight to restore individual's choice and your strategy to create entry barriers for startups in name of responsibility."
Security vs. Anti-Competitive Moats
No one argues against security. Mail apps handle sensitive user data. Mitsa uses Argon2id for password hashing with unique salts, runs behind TLS 1.3 with strict HSTS, prevents SQL injection through compile-time parameterized queries via sqlx, and isolates tenant queries at the database layer. I have zero objection to automated security checks or transparent audits.
The problem is the mandatory financial gate.
When access to an API requires an annual cash payment to an approved third-party cartel:
- It acts as a private tax on software development. Google does not collect the check directly, but they mandate who you must pay to get a permission slip.
- It eliminates indie software. Any student, hobbyist, or solo founder who builds an email client is immediately barred from letting ordinary users sign in unless they pay an annual toll.
- It redefines user consent. When an adult user clicks "Sign in with Google" and explicitly grants permission for an app to read their email, Google steps in and says: We don't care that you consented. The developer hasn't paid our approved assessor yet.
If Google wants rigorous security verification for apps using its APIs, Google—a multi-trillion-dollar company—can easily run automated verification pipelines or fund assessments for small developers. Making a $700+ recurring fee the barrier to entry ensures that only funded startups and enterprise incumbents can build mail software.
The Workaround: Why IMAP Still Matters
The irony of Google's walled garden is that email was never supposed to be an API. It is an open protocol.
Google only imposes this CASA requirement on its proprietary REST APIs. It cannot impose it on standard IMAP and SMTP.
Any Gmail user can go into their Google Account settings, generate a 16-character App Password, and connect any mail client they want via imap.gmail.com. It requires zero approvals, zero CASA audits, and zero dollars paid to third-party labs.
That is the route Mitsa Mail is taking. Rather than paying Google's annual toll, we are adding standard IMAP/SMTP support. The side effect is positive: instead of just supporting Gmail, the app will support Outlook, Yahoo, Fastmail, and self-hosted mail servers out of the box.
Still, the underlying policy needs to be called out. Gatekeeping user data behind compliance fees masquerading as consumer protection is anti-competitive. If independent software is going to survive on the modern web, users—not platform monopolies—must have the final say on who they share their data with.