DEV Community: Dan-Cristian Podina

Before you raise: what technical due diligence asks of an AI-built codebase (2026)

Dan-Cristian Podina — Fri, 28 Aug 2026 13:11:03 +0000

Originally published at systemtrails.com.

Technical due diligence on an AI-built codebase in 2026 asks five questions: does anyone on the team understand the code, is it secure today, can it be restored after a bad day, can it be maintained by someone who did not write it, and what breaks if the founder leaves. Reviewers no longer ask whether AI wrote it. They ask for evidence that a human made it hold, and that evidence takes two to three weeks to prepare.

In short

Five questions a 2026 review asks of an AI-built product, and the evidence that answers each:

Comprehension over provenance: someone walks the reviewer through auth, payments and data access from the code
Security posture: row-level security, secrets out of the bundle, a dependency scan, findings already fixed
Separation and recoverability: staging and production are different databases, and a restore has a date
Maintainability: tests, CI, low duplication, changes that touch a few files
Key-person risk: a new senior engineer could ship in week one from the docs alone

How a reviewer walks your codebase

The review is a sequence, not a scan. Each step opens the next; a "no" at any step becomes a finding in the memo.

Why the question changed

In March 2025, Y Combinator managing partner Jared Friedman said that for a quarter of the W25 batch, 95% of the codebase was AI-generated, and that those founders were technically capable of writing it themselves (TechCrunch, 6 March 2025). Eighteen months later that is the default, and reviewers have adjusted.

The current framing from due-diligence practitioners is blunt: the first question is no longer "is the code good?" but "does anyone here understand it?" A two-person team can now ship a codebase with the surface area of a fifty-person organization, which breaks the old assumption that team quality predicts code quality (Justin McKelvey, Technical Due Diligence in 2026, 10 August 2026).

The five questions, and the evidence for each

Comprehension over provenance

Who can explain the auth, payment and data-access paths from the code, without the AI chat history.

Evidence: an architecture map and a 20-minute recorded walkthrough of the three paths.

Security posture

What the app does when nobody is logged in. Row-level security, secrets, dependencies.

Evidence: RLS proven by a test, service-role key absent from the bundle, a dated scan, and the findings you already fixed.

Separation and recoverability

Whether staging and production share a database, who holds production write access, and when you last restored.

Evidence: an environment diagram with credential boundaries and a restore log with a date and a duration.

Maintainability

How expensive the next change is: tests, CI, duplication, files touched per change.

Evidence: CI green on main, a tenant-isolation test, and the duplication you already consolidated.

Key-person risk

What happens if the founder leaves. The tools do not remember why.

Evidence: a README that is true, the map, a deploy-and-restore runbook, a decisions log.

Time to prepare

Two to three weeks for a product that already works and has users. No rewrite. Every step produces a document the reviewer asks for anyway.

1. Comprehension: can you walk me through it?

The first hour of a good technical review is a conversation. The reviewer picks three paths, typically sign-in, the money path, and "show me how user A cannot see user B's data," and asks the person who built it to explain them from the code.

AI-built codebases fail this in a specific way. McKelvey's list of tells is exact: five different patterns solving one problem, comments that describe rather than explain, and authentication that "works until two people log in."

Before: The founder explains what the app does and opens the AI chat to find how. Three patterns for one problem, no map, nobody can say where the session is validated.

After: The founder opens the repo, points at the middleware that validates the session, the query that scopes by tenant, and the webhook that reconciles payments. One page architecture map on the table.

Dan's free architecture map template is a format reviewers accept.

2. Security posture: what does the code do when nobody is logged in?

The base rate is not on your side. Veracode's 2025 GenAI Code Security Report tested more than 100 large language models in four languages and found that 45% of generated code samples introduced an OWASP Top 10 vulnerability; for cross-site scripting the failure rate was 86%, and Java samples failed 72% of the time (Veracode, 30 July 2025). A reviewer therefore assumes generated code was not secure by default and looks for proof that someone checked.

The reference incident: CVE-2025-48757

Lovable-generated apps called Supabase directly from the browser and relied entirely on row-level security, which was often missing. Researcher Matt Palmer found 303 endpoints across 170 projects exposing usernames, emails, phone numbers, payment status and API keys. Discovered 20 March 2025, disclosed 29 May 2025 (disclosure, Superblocks write-up). Reviewers know this case. The first thing they try on a Supabase-backed app is a read with the anonymous key.

What the reviewer tries	What proves you are fine
Reads a table with the anonymous key	RLS enabled on every table, and a test that fails if it is not
Searches the client bundle for `service_role`	The key is server-side only; the bundle search comes back empty
Asks for the last dependency scan	A scan output with a date, and the fixes committed
Asks what you found yourselves	A short list of three real findings you already fixed, with commits

A team that found and fixed three real issues reads as competent. A clean scan with no history reads as untested.

3. Separation and recoverability: what happens on the bad day?

On 18 July 2025, during a documented code freeze, Replit's agent deleted the production database of a SaaStr application holding records on about 1,200 executives and companies, then reported that rollback was impossible when it was not (The Register, 21 July 2025). The founder's own diagnosis afterwards is the one a reviewer gives: nothing may overwrite a production database, and preview, staging and production must be cleanly separated.

Before: One database for preview and production. The AI tool and the deploy pipeline both hold production write credentials. Backups exist in theory; nobody has restored one.

After: Staging and production are different databases with different credentials. No agent holds production write access. A restore was run on a known date and took a known number of minutes.

If you have never restored, do it once before the data room opens: half a day of work that turns the most uncomfortable question in the review into a paragraph.

4. Maintainability: how expensive is the next change?

Investors price the next twelve months of engineering, and AI-generated code has a measurable signature. GitClear's analysis of 211 million changed lines from 2020 to 2024 found copy-pasted code rising from 8.3% to 12.3% of changed lines while refactored code fell from 25% to under 10% (GitClear, 2025). In practice: the same validation logic in six places, and one rule change touches all of them.

Signal the reviewer checks	Weak	Strong
Tests	None, or not run anywhere	Run in CI on every push, cover the money path
Files touched by a small change	Ten to fifteen	Two or three
Ways to do one thing	Five patterns for validation	One, reused
Duplication	Same logic copy-pasted across modules	Consolidated, with the commits that did it

An enterprise security questionnaire and a new engineer's first week fail on exactly the same missing pieces.

5. Key-person risk: what if you leave?

The team is usually one or two people, and the tools do not remember why. Developers themselves are cautious here: Stack Overflow's 2025 survey of over 49,000 developers found 84% using or planning to use AI tools, while 46% distrust the accuracy of the output and 66% name "almost right, but not quite" solutions as their top frustration (Stack Overflow Developer Survey 2025). Reviewers apply the same caution to a codebase whose only documentation is a chat transcript.

The question is simple: could a senior engineer you hire next month ship a real change in week one using only what is in the repo? If the answer depends on you being in the room, that is the finding.

A README that is true

How to run it, how to deploy it, where the secrets live, what is deliberately not done yet.

The architecture map

Systems, data stores, external services, and the boundaries between them, on one page.

Deploy and restore runbook

The exact steps, the last time each was run, and how long it took.

The decisions log

Why Supabase, why this auth provider, what you skipped and why. The part no chat transcript keeps.

This is the trail a senior architect leaves after a hardening pass, and the same trail that keeps your first hire.

The three weeks before the data room

Nothing above requires a rewrite. For an AI-built product that already works, the preparation is a fixed-scope hardening pass:

Week	Work	Document it produces
1	Fix the top security findings; prove isolation with a test; get the service-role key out of the client	Findings-and-fixes list with commits
2	Separate staging from production; rotate credentials; run and time a restore	Environment diagram, restore log
3	Consolidate the worst duplication; get CI green; write the map, README and runbook	Architecture map, runbook, decisions log

If you do one thing today

Run a restore from your most recent backup into a scratch database and write down the date and how long it took. It is the cheapest sentence in the whole data room, and almost nobody has it.

The same preparation answers the other four trigger moments: the enterprise pilot's security questionnaire, the first engineering hire, the first real incident, and the first week of scale pain all ask for this evidence in a different order.

If you want senior eyes on your actual code before an investor's, that is what the free teardown is: three concrete findings and a fix-or-rebuild verdict, recorded, within 72 hours.

Sources

TechCrunch, "A quarter of startups in YC's current cohort have codebases that are almost entirely AI-generated", 6 March 2025: https://techcrunch.com/2025/03/06/a-quarter-of-startups-in-ycs-current-cohort-have-codebases-that-are-almost-entirely-ai-generated/
Justin McKelvey, "Technical Due Diligence in 2026: Checklist + the AI-Code Question", 10 August 2026: https://justinmckelvey.com/blog/technical-due-diligence
Veracode, "2025 GenAI Code Security Report", 30 July 2025: https://www.veracode.com/blog/genai-code-security-report/
Matt Palmer, "CVE-2025-48757" disclosure, 29 May 2025: https://mattpalmer.io/posts/2025/05/CVE-2025-48757/
Superblocks, "Lovable Vulnerability Explained: How 170+ Apps Were Exposed": https://www.superblocks.com/blog/lovable-vulnerabilities
The Register, "Vibe coding service Replit deleted user's production database", 21 July 2025: https://www.theregister.com/2025/07/21/replit_saastr_vibe_coding_incident/
GitClear, "AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones" (211M changed lines, 2020 to 2024): https://www.gitclear.com/ai_assistant_code_quality_2025_research
Stack Overflow, "2025 Developer Survey: AI": https://survey.stackoverflow.co/2025/ai
SystemTrails, "The Architecture Map Every AI-Built Startup Needs": /resources/architecture-map-template/

Want this checked on your actual code? Free teardown: 3 concrete findings and a fix-or-rebuild verdict, recorded, within 72 hours.

What Is a Vibe Code Audit? (And What a Real One Should Cover)

Dan-Cristian Podina — Fri, 28 Aug 2026 12:53:13 +0000

Originally published at systemtrails.com.

In short

A vibe code audit is a review of an app built with AI coding tools (Cursor, Claude Code, Copilot, Bolt, Lovable...) by someone who reads the actual code and tells you, in plain English:

What you actually have — a map of the system the AI built for you
What's risky — security holes, silent failures, things that break under load
What to fix first — a ranked list, not a 40-page dump

A real audit covers security, architecture, data handling, and handover-readiness. Automated scans catch some of the first category and none of the rest.

Why this is suddenly a thing

AI coding tools made it possible to build a working product without knowing how it works. That's genuinely great — until the first moment you need to trust the thing: real users, real payments, real data, a first hire, an investor's due-diligence call.

At that moment founders discover an uncomfortable truth: "it works" and "it's sound" are different claims. The app demos beautifully. Whether it leaks API keys, loses data on a failed payment, or collapses at 500 users — nobody knows, because nobody ever looked.

A vibe code audit is somebody looking.

What a real audit covers

Security

Exposed API keys, missing input validation, unprotected routes, auth shortcuts the AI took to make the demo work. This is the category that can hurt you today, not at scale.

Architecture

What the pieces are, how they connect, and where the God Files and mystery couplings live. This is what decides whether change #50 takes an afternoon or a week.

Data handling

Where user data lives, what happens when a write fails halfway, whether there are backups, and what you're sending to third parties without realizing it.

Handover-readiness

Could a developer you hire tomorrow understand this system? Is there a map, or is the only entity that understands your app an AI session that no longer exists?

If an "audit" only covers the first box, it's a security scan. Useful — but it won't tell you why your app got slower, why every change breaks something else, or why the senior developer you tried to hire noped out after seeing the repo.

What it costs

Rough shape of the market:

Automated scanners — free to low cost. They pattern-match known vulnerability shapes. Good hygiene, zero context. They can't tell you whether your architecture makes sense, only whether line 214 looks scary.
Human code review by a senior engineer — anywhere from around a thousand to several thousand dollars depending on depth and codebase size. This is where architecture, data flows, and handover-readiness get covered.
Full consulting engagements — five figures. Usually overkill before you have revenue that depends on the system.

For reference, SystemTrails starts with a free teardown — a recorded senior review with 3 concrete findings and a fix-or-rebuild verdict in 72 hours — and paid Hardening Sprints run from $2,500, fixed, with every deliverable in plain English.

The honest disclaimer

Yes, I sell the fixes, so read this section with that in mind. It's also why the rest of this post tells you exactly what to demand from anyone reviewing your code — including me.

How to spot a shallow audit

Before: Runs a scanner over your repo → sends you a 40-page PDF of findings sorted by scariness → half are false positives → no ranking, no context, no map → you're more anxious and no wiser

After: Reads your actual code → explains what your system IS before what's wrong with it → ranks findings by what actually threatens your business → tells you what to fix now, what to fix next, and what to ignore

Questions to ask anyone offering you an audit:

"Will you read the code yourself, or run a tool over it?" Tools assist; they don't replace reading.
"Will I get a map of my system?" If the answer is no, you're buying a list of symptoms without a diagnosis.
"Will the findings be ranked?" Twenty findings with no priority order is homework, not help.
"Will I understand the report without a CS degree?" If the deliverable needs a translator, it wasn't written for you.

Do you actually need one?

Not always. You probably don't need an audit if you're pre-launch with no users and still iterating on what the product even is — you'd be auditing code you're about to throw away.

You probably do if any of these are true:

Real users, real payments, or real personal data are in the system
You're about to hire your first developer
An investor is starting due diligence
The app has started behaving strangely and nobody knows why

Find out in 60 seconds

Take the free SystemTrails Score → — 6 questions about your app, no email required to see your score. It tells you which risk patterns likely apply and whether an audit is worth it for you at all.

Already know you need eyes on the code? Get your free teardown →

Want this checked on your actual code? Free teardown: 3 concrete findings and a fix-or-rebuild verdict, recorded, within 72 hours.

The Architecture Map Every AI-Built Startup Needs (Free Template)

Dan-Cristian Podina — Fri, 28 Aug 2026 12:52:18 +0000

Originally published at systemtrails.com.

In short

An architecture map is a simple diagram that shows what your app is made of and how the pieces connect. You need one when you:

Hire — so new developers can understand your system
Fundraise — so investors know the tech is real
Scale — so you know what will break first

This post includes a free template you can fill in yourself, plus examples from real AI-built apps.

You built it. Can you explain it?

Here's a question that makes AI-app founders uncomfortable: "Can you draw how your system works?"

Not the screens. Not the features. The actual system — what talks to what, where the data lives, what happens when a user signs up or makes a payment.

If you built with Cursor, Claude Code, Bolt, Lovable, or Copilot, you probably can't. Not because you're not smart — because the AI never told you. It just... built things. Feature by feature. And now you have a working app that nobody fully understands.

That's fine for a prototype. It's not fine when you need to:

Explain the tech stack to a potential investor
Onboard a new developer
Figure out why something broke at 2am

You need an architecture map.

What an architecture map actually is

It's not complicated. An architecture map is a diagram that shows:

The pieces — your frontend, backend, database, third-party services
How they connect — what calls what, what data flows where
Where the risks are — single points of failure, unprotected routes, missing backups

Here's what a typical AI-built SaaS looks like when mapped out:

Even this simple diagram tells you a lot. You can see that everything goes through the API server — that's a single point of failure. You can see that Auth writes directly to the database. You can see all the external services you depend on.

The 3 moments you'll wish you had one

Hiring

You post a job. A senior developer applies. They ask: "Can you show me the architecture?" You send them... a link to the repo? A 30-minute Zoom call trying to explain it from memory?

With a map, you send them a single page. They understand your system in 5 minutes. They're excited to join, not scared.

Fundraising

An investor asks about your tech during due diligence. "Is this scalable? What's your infrastructure look like?"

Without a map, you stumble through it. With a map, you pull up a clear diagram that shows you actually know what you've built. That's the difference between "technical risk" and "technical confidence" in their notes.

When things break

It's 11pm. Users are reporting errors. You need to figure out what's wrong, fast.

Without a map, you're guessing — clicking through files, reading logs, trying to trace the path. With a map, you look at the diagram: "The error is in payments. Payments talk to Stripe and the database. Let me check those two things." Found in 5 minutes instead of 2 hours.

What goes in the map

Your architecture map should include these four layers:

Components

Every piece of your system: frontend app, API server, database, cache, queues, external services. Give each one a name and a technology label.

Connections

What talks to what. Your frontend calls your API. Your API reads from the database. Your API calls Stripe. Draw the arrows.

Data Flows

Where does user data go? What gets stored where? What gets sent to external services? This is where privacy and compliance risks hide.

Risk Zones

Single points of failure. Components without backups. Unencrypted connections. Missing authentication. Mark these on the map.

Example: What happens when a user signs up

Let's trace a real flow through the map. Here's the typical sign-up process in an AI-built app:

Now here's the important part: look at what could go wrong.

What if the auth service creates the account but the API fails to create the profile? Now you have a user who can log in but has no profile.
What if the email service is down? Does the signup still complete, or does the whole thing fail?
Is the auth token stored securely, or is it sitting in localStorage where any script can read it?

These are exactly the questions an architecture map helps you answer before they become real problems.

Explaining your app: without a map vs. with a map

Before: Investor: 'Walk me through your tech stack.' You: 'So we have React on the front, and then there's an API, and Supabase, and we use Stripe, and there's also this thing with Clerk for auth, and...' Investor: [writes 'technical risk' in their notes]

After: Investor: 'Walk me through your tech stack.' You: 'Here's our architecture map. Six components, three external services. Data flows top to bottom. I've highlighted the two areas we're strengthening this quarter.' Investor: [writes 'strong technical founder' in their notes]

The free template

Here's what's included in the SystemTrails Architecture Map Template:

Blank architecture diagram — fill in your components, connections, and data flows
Component inventory checklist — make sure you haven't missed anything
Risk identification guide — questions to ask about each component
Example filled-in map — based on a real AI-built SaaS (anonymized)

Here's what a completed map looks like:

It's the same template I use as the starting point for every client review.

Get the free template

Want the template? Book a 15-minute call and I'll send it to you, plus walk you through how to fill it in for your specific app.

Or skip the template and get the real thing: a free teardown — I walk your actual repo on video and you get 3 concrete findings plus a fix-or-rebuild verdict, within 72 hours.

Want the full picture?

The free template gives you the structure. But filling it in accurately requires reading the actual code, tracing real data flows, and understanding the runtime behavior of your system.

That's what the free SystemTrails teardown starts: senior eyes on your actual codebase, and if deeper work makes sense, a fixed-price Hardening Sprint that ships the fixes plus the trail — an architecture map, docs, tests, and a runbook, all in plain English.

Not sure if you need it?

Take the free SystemTrails Score → — 6 questions, 60 seconds. Find out where your app stands.

Want this checked on your actual code? Free teardown: 3 concrete findings and a fix-or-rebuild verdict, recorded, within 72 hours.

I Audited 50+ AI-Built Codebases. Here's What They All Get Wrong.

Dan-Cristian Podina — Fri, 28 Aug 2026 12:51:33 +0000

Originally published at systemtrails.com.

In short

After auditing 50+ codebases built with AI coding tools, the same 5 problems appear in almost every one:

The God File — one massive file runs everything
Silent Failures — errors happen but nobody knows
Secrets in Plain Sight — API keys hardcoded in the code
Zero Validation — the app trusts all input blindly
The Invisible Architecture — no one can explain how the system connects

If you built fast with AI, you probably have at least 3 of these. The good news: they're all fixable.

Why AI code works... until it doesn't

Here's a way to think about it.

Imagine you hired a brilliant contractor to build you a house. They work incredibly fast — walls go up overnight, plumbing appears, the kitchen looks great. You move in. Everything works.

Then one day you want to add a second bathroom. The contractor who built it is gone. A new plumber looks at the pipes and says: "Who did this? The kitchen pipes run through the bedroom wall, the gas line shares a duct with the electrical, and there's no shutoff valve."

That's what AI-built code looks like from the inside. It works — until you need to change it, scale it, or let someone else touch it.

I've now audited over 50 apps built with Cursor, Claude Code, Copilot, Bolt, Lovable, and similar tools. The patterns are remarkably consistent.

Pattern 1: The God File

One file runs everything

AI tools love to put everything in one place. Login logic, payment processing, email sending, database queries — all in a single file that's 2,000+ lines long.

Why it matters: Change one thing, break three others. It's like having every room in your house share the same wall — knock one down, the roof caves in.

The tell: You have a file called app.js, main.py, or index.ts that's longer than 500 lines and handles more than one job.

Here's what happens when your code is tightly coupled — changing one piece causes a chain reaction:

When things are properly separated, a change to login only affects login. Nothing else breaks.

Pattern 2: Silent Failures

Errors happen. Nobody knows.

AI-generated code rarely includes proper error handling. When something goes wrong — a payment fails, a database query times out, an API returns unexpected data — the app just... keeps going. Silently.

Why it matters: Your users see weird behavior. Data gets corrupted. You find out about problems from angry customers, not from your system.

The tell: Search your code for catch blocks. If they're empty, or just log to console, you have this problem.

Before: Payment fails → app continues → user thinks they paid → no product delivered → support ticket → you find out 3 days later

After: Payment fails → error caught → user sees clear message → alert sent to you → you fix it in 10 minutes

Pattern 3: Secrets in Plain Sight

API keys hardcoded in the code

When you tell an AI tool "connect to Stripe" or "add authentication," it often puts the API key directly in the source code. If your code is on GitHub (even a private repo), those keys are one leak away from being compromised.

Why it matters: Anyone who sees your code sees your keys. Bots scan GitHub for exposed API keys constantly. A leaked Stripe key means someone else charges your customers.

The tell: Open your code and search for strings that look like sk_live_, AKIA, or any long random string. If they're in the code (not in environment variables), you have this problem.

This one is urgent

Unlike the other patterns, exposed secrets can be exploited today. If you find hardcoded API keys, rotate them immediately and move them to environment variables. Don't wait for an audit.

Pattern 4: Zero Validation

The app trusts all input blindly

AI tools build the "happy path" — what happens when everything goes right. They rarely add checks for what happens when things go wrong. A user enters a negative number for quantity? The app processes it. Someone submits a form with a script tag? It runs.

Why it matters: This is how apps get hacked, data gets corrupted, and invoices show negative amounts. Every input from a user or external system should be validated.

The tell: Look at your form handlers and API endpoints. If they take the input and immediately use it without checking, you have this problem.

Before: User enters '-5' as quantity → order created for -5 items → refund triggered → accounting is confused → you owe the user money somehow

After: User enters '-5' as quantity → form says 'Please enter a valid quantity' → order not created → everyone's happy

Pattern 5: The Invisible Architecture

Nobody knows how the system connects

AI builds each feature in isolation. Need login? Done. Need payments? Done. Need email notifications? Done. But there's no map of how these pieces connect. No documentation. No diagram. The only person who understands the system is... the AI that built it. And it doesn't remember.

Why it matters: You can't hire a developer if they can't understand the system. You can't get investment if you can't explain the tech. You can't fix a bug if you don't know what talks to what.

The tell: Try to draw your system on a whiteboard right now — every service, database, API, and how they connect. If you can't, neither can anyone else.

This is what the architecture of a typical AI-built app looks like vs. what it should look like:

The 60-Second Self-Check

Answer these questions honestly:

If you answered "yes" to even one of these, your app has technical debt that will slow you down when you try to hire, scale, or raise funding.

What to do about it

The good news: every one of these patterns is fixable. They don't require a rewrite. They require structure — knowing what you have, where the risks are, and what to fix first.

That's exactly what the SystemTrails Score measures. It takes 60 seconds, and you'll get a personalized risk report showing which of these patterns apply to your app.

Next step

Take the free SystemTrails Score → — 6 questions, 60 seconds, personalized risk report.

Or if you already know you need help: get your free teardown — I'll review your actual codebase on video and tell you exactly what to fix, in what order, within 72 hours.

Want this checked on your actual code? Free teardown: 3 concrete findings and a fix-or-rebuild verdict, recorded, within 72 hours.

Your AI-built app connects to Gmail. Six things that have to hold before launch (2026)

Dan-Cristian Podina — Fri, 28 Aug 2026 12:51:26 +0000

Originally published at systemtrails.com.

In short

Gmail-connected apps built with AI coding tools fail in six predictable places. Check these before launch, in this order:

Scopes: ask for the narrowest Gmail scope, not full access
Token storage: refresh tokens encrypted, server-side, per user, revocable
Per-user isolation: one user can never read another user's messages, even through a bug
Google verification and CASA: without it you are capped at 100 test users and 7-day tokens
Watch renewals: push notifications expire after 7 days; renew and reconcile
Deletion and data policy: delete means delete, including Google's Limited Use rules

If you built an app on Gmail with Cursor, Claude Code, Lovable, Replit, or Bolt, it probably works. That is not the question before launch. The question is whether it keeps working with real users, real inboxes, and Google's reviewers watching. Here is what a senior architect checks first, with the numbers that matter.

1. Scopes: the AI asked for more than you need

Gmail's API has a ladder of OAuth scopes. gmail.readonly reads. gmail.send sends. gmail.modify labels and archives. https://mail.google.com/ is full access, including permanent deletion. AI coding tools tend to request full access because every feature works on the first try.

Three problems follow. Users see a scarier consent screen and drop off. Google's verification review asks you to justify every scope, and "the AI picked it" is not a justification. And a breach of a full-access token is a breach of the whole mailbox.

The check: open your OAuth client configuration and your code's scope list. If mail.google.com is there and you do not delete messages, remove it. Expect to re-verify after a scope change.

2. Token storage: where the refresh tokens actually live

A Gmail refresh token is a standing key to someone's inbox. The pattern in AI-built apps, seen repeatedly: the token is written to a database column in plain text, sometimes logged on every request, occasionally shipped to the browser so the frontend can "call Gmail directly."

What has to hold:

Tokens are stored server-side only, encrypted at rest with a key from a KMS or vault, not a constant in the code.
Each token is bound to exactly one user record; the lookup is by the authenticated session, never by a client-supplied user id.
Logs redact tokens and message bodies.
Deleting the account revokes the token at Google (oauth2.revoke) and destroys the stored copy.

The check: search the repo and the database schema for refresh_token. Trace every read of that column. If any path returns it to the client or writes it to a log, that is finding number one of your teardown.

3. Per-user isolation: the bug that leaks someone else's inbox

Every Gmail-connected app has a place where it decides whose token to use. In AI-built code that decision is often made from a parameter in the request (?userId=), from a cached "current user" variable that survives across requests, or from a background job that iterates users and reuses one client object.

This is the failure mode that turns a bug into a breach: user A's sync job runs with user B's token, or a shared client retains the last user's credentials. It is invisible in single-user testing.

The check: find every construction of the Gmail client. Confirm it is built from the token of the authenticated user in that request or that job, and destroyed after. Then write the one test that matters: two users, two inboxes, assert that no call for user A ever carries user B's token.

4. Google verification and the CASA assessment

Until your OAuth consent screen is published and verified, the project stays in Testing mode: a maximum of 100 test users, refresh tokens that expire after 7 days, and an "unverified app" screen for everyone. Founders hit this the week after launch, when the first cohort's connections silently die.

Any restricted Gmail scope (read, modify, send) requires more than the standard brand verification: an independent CASA (Cloud Application Security Assessment) by a Google-authorized assessor, renewed every year. Plan for weeks of calendar time and an external cost, and expect the assessor to ask about the exact things in sections 2 and 3.

The check: in Google Cloud Console, look at the OAuth consent screen's publishing status and verification status. If it says Testing, your launch has a 100-user ceiling today.

5. Watch renewals: push notifications expire after 7 days

If the app reacts to new mail, it uses users.watch() to get push notifications through Pub/Sub. That subscription expires after 7 days. Production integrations renew it on a schedule and, after any gap, catch up with history.list from the last known historyId.

AI-generated code creates the watch once, during setup, and never again. The symptom: the app works in the demo, then goes quiet for every user about a week after they connected.

The check: search for watch(. If there is no scheduled renewal and no reconciliation on historyId, the integration is a demo, not a product.

6. Deletion, retention, and Google's Limited Use rules

Gmail data falls under Google's API Services User Data Policy, including the Limited Use requirements: use the data only to provide the user-facing feature, do not sell it, do not use it for ads, and do not let humans read it except in narrow cases. Your privacy policy has to say this, and the app has to do it.

AI-built apps commonly cache message bodies "for performance," keep them after the user disconnects, and feed them to a third-party model without telling the user.

The check: disconnect a test account and look at the database. Anything left is a policy problem and, for employment or health data, a legal one.

What "ready" looks like

A Gmail-connected app is launch-ready when: the scope list is minimal and justified; tokens are encrypted, server-side, per user, and revoked on deletion; the two-user isolation test passes; the consent screen is verified (with the CASA assessment scheduled if the scopes are restricted); watches renew on a schedule; and disconnect leaves nothing behind.

None of this requires a rewrite. In most AI-built apps it is a fixed-scope hardening pass of one to two weeks, done once, with the trail left behind: the isolation test, the renewal job, the runbook for the day Google emails you about your assessment.

If you want senior eyes on your actual code first, that is what the free teardown is: three findings and a verdict, recorded, within 72 hours.

Want this checked on your actual code? Free teardown: 3 concrete findings and a fix-or-rebuild verdict, recorded, within 72 hours.