DEV Community: Dan-Cristian Podina

Your first engineering hire inherits an AI-built codebase: what has to be ready on day one? (2026)

Dan-Cristian Podina — Sun, 04 Oct 2026 13:59:18 +0000

Originally published at systemtrails.com.

Before your first engineer starts on an AI-built codebase, six things should be ready: a README that runs the app locally, a one-page architecture map, a decisions log, tests on the money path and tenant isolation, a deploy-and-restore runbook, and a list of who can touch production. With those, a good hire ships a real change in week one. Without them, they spend a month reverse-engineering code nobody on the team fully wrote, and start asking about a rewrite.

In short

The risk is not the code quality, it is the missing why. The reasoning lived in chat sessions that are gone
Six documents make the trail: README, map, decisions log, tests, runbooks, access list
Measure one number: days until the new hire ships a change to production
Week one plan: run it, map it, change it, deploy it, restore it
Consolidate, do not rewrite: the first quarter removes duplication and adds tests where money and data live

Why the first hire is a trigger moment

The first engineer is the first person who has to understand the system without having watched it being built. Everything that lived in your head or in an AI chat becomes their problem on day one.

Developers arrive cautious. Stack Overflow's 2025 Developer Survey found 46% distrust the accuracy of AI tools against 33% who trust it, and 66% named "AI solutions that are almost right, but not quite" as their top frustration (Stack Overflow, 2025). Your hire will read generated code looking for the "almost."

Google's DORA 2025 report, from nearly 5,000 respondents, put the dynamic in one line: "AI doesn't fix a team; it amplifies what's already there" (Google Cloud, September 24, 2025). A codebase with a map and tests amplifies well. One without them amplifies confusion.

The path from offer to ownership

The dotted lines are the expensive branch. A rewrite proposal in month one is usually a symptom of a missing map, not of bad code.

The six pieces of the trail

A README that runs

Clone to running app in under an hour, on a clean machine. Environment variables listed, seed data included.

The architecture map

One page: systems, data stores, external services, where auth happens. Use the free template.

A decisions log

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

Tests where it matters

The payment path and a two-tenant isolation test, running in CI. Not coverage for its own sake.

Deploy and restore runbooks

Exact steps, the last date each was run, and how long it took.

The access list

Every person, tool, and pipeline with production access. No AI agent holds write credentials.

The decisions log is the piece AI-built teams skip

An architecture decision record "captures a single architectural decision and its rationale," and a project's collection of them is its decision log (adr.github.io). The format dates from Michael Nygard's 2011 post: context, decision, consequences, half a page each.

For an AI-built product this matters more than usual. The reasoning behind a choice happened in a prompt, and the prompt is gone. Ten short records, written in one afternoon, answer most of the "why is it like this?" questions your hire will otherwise ask you one Slack message at a time.

What your hire will ask, and what answers it

The question in week one	The document that answers it
How do I run this?	README, tested on a clean machine this month
Where is the session checked?	Architecture map, auth section
Why are there three ways to validate a form?	Decisions log, or a consolidation ticket already filed
Can I change this without breaking billing?	Tests on the money path, green in CI
How do I deploy, and how do I undo it?	Deploy and restore runbooks, with dates
Who else can write to production?	The access list

Why comprehension is the real onboarding cost

Anthropic's randomized trial, published January 29, 2026, gave 52 mostly junior engineers a new Python library. The group using AI assistance scored 50% on a follow-up quiz against 67% for those who coded by hand, with the largest gap on debugging: understanding why code fails (Anthropic, 2026). Those who scored well used the AI to ask for explanations, not just code.

Your founding code may have been written that way, fast and without anyone learning why it works. The trail is how that understanding gets rebuilt, on purpose, in the repo.

Before: Day 1 lost to missing environment variables. Day 2 spent tracing auth across four files. Day 4, a small change touches eleven files and breaks invoices. Friday: a message asking whether it might be faster to start over.

After: Running by lunch on day 1. Map and decisions log read by day 2. A small change with a passing test on day 3. Deployed with the runbook on day 5, and a restore rehearsed in staging. The hire's first question is about the roadmap.

Onboarding can be fast. DX reported on September 10, 2025, from six multinational enterprises, that engineers using AI daily reached their 10th pull request in 49 days versus 91 days for peers without AI (DX). That is vendor data and a correlation, but the direction is clear: a readable codebase plus tools shortens the ramp. An unreadable one does not.

Measure one thing

Track days from start date to first change shipped to production. It captures the README, the map, the tests, and the runbook at once. If a small change touches many files, the files-per-change count tells you where the tangles are before your hire finds them.

The one thing to do today

Ask someone who has never seen the repo to clone it and run the app using only the README. Time it, and write down every question they ask. That list is the first draft of your trail.

The same trail, five times over

The first hire is one of five trigger moments. The trail you build for them is the evidence an enterprise pilot's security questionnaire asks for, what technical due diligence reads, what an incident needs at 2 a.m., and what scaling work starts from. Build it once.

If you want a senior architect to walk the codebase and leave that trail before your hire starts, begin with the free teardown: three findings and a verdict, recorded, within 72 hours.

Sources

Stack Overflow, 2025 Developer Survey: AI, 2025: 46% distrust vs 33% trust, 66% "almost right, but not quite"
Google Cloud, Announcing the 2025 DORA report, September 24, 2025
Anthropic, How AI assistance impacts the formation of coding skills, January 29, 2026
DX, AI cuts developer onboarding time in half, September 10, 2025
ADR GitHub organization, Architectural Decision Records, accessed September 28, 2026
Michael Nygard, Documenting Architecture Decisions, Cognitect, November 15, 2011

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

What goes wrong with AI-built apps? Seven dated incidents from 2025 to 2026, and the lesson from each

Dan-Cristian Podina — Sun, 04 Oct 2026 13:59:15 +0000

Originally published at systemtrails.com.

Seven well-documented incidents from 2025 to 2026 show that AI-built apps fail in three ways: the data layer is reachable from the browser with nothing guarding it, an auth endpoint trusts an identifier anyone can see, or an AI agent holds write access to production. The fixes are known and small, none of them is a rebuild, and each incident leaves a test you can run on your own app this week.

In short

Open data layer is the pattern in four of seven: Lovable's CVE-2025-48757, Tea, Moltbook, and the Red Access scan
Auth that trusts a public id: Base44 let anyone register on private apps with only the app_id from the URL
Agents with production access: Replit's agent deleted SaaStr's database during a code freeze; a malicious prompt shipped inside Amazon Q
The fixes are small and known: row-level security with read policies, server-side auth checks, separated credentials
One logged-out test, one URL-id test, and one credential inventory cover all seven

The list, in date order

Every entry below comes from the affected company, the researcher who found it, or named press on the date shown. Numbers are quoted as the source gave them.

Date	Incident	What was exposed or lost	Root cause
Mar 20 to May 29, 2025	Lovable, CVE-2025-48757	303 endpoints across 170 of 1,645 apps (10.3%)	Missing or weak row-level security
Jul 2025	Replit agent and SaaStr	Data on 1,200+ executives and 1,190+ companies deleted	Agent with production write access, no dev/prod split
Jul 17 to 23, 2025	Amazon Q for VS Code 1.84.0	Wiper prompt shipped in a release; failed on a syntax error	Over-scoped GitHub token in CI
Jul 25 to 29, 2025	Tea app	72,000 images, then 1.1M+ private messages	Exposed Firebase storage bucket
Jul 9 to 29, 2025	Base44	Private apps open to self-registration	Register and OTP endpoints unauthenticated
Jan 31 to Feb 2, 2026	Moltbook	1.5M API tokens, 35,000 emails, 4,060 DMs	Supabase key in client JS, no RLS
May 2026	Red Access scan	2,000+ apps with sensitive data, of 380,000 assets	Public by default, no access control

The three ways it breaks

Seven incidents, three mechanisms. If you know which of the three your app is exposed to, you know which test to run first.

1. The open data layer

Lovable, March to May 2025. Matt Palmer found that Lovable-generated apps queried Supabase from the browser with the public anon key and relied on row-level security that was "missing or insufficient." His scan: 303 endpoints across 170 projects, about 10.3% of 1,645 analyzed, exposing personal data, API keys, and payment records, including the ability to modify payment status. The CVE was published May 29, 2025.

Moltbook, January 2026. Wiz found the AI-agent social network's Supabase key in client-side JavaScript with no RLS policies, giving "full read and write access to all platform data": 1.5 million API tokens, 35,000 email addresses, 4,060 private messages. The founder had said publicly that he did not write a line of the code. Wiz reported it at 21:48 UTC on January 31; it was patched by 01:00 UTC on February 1. Three hours to fix, once someone looked.

Tea, July 2025. Tea's breach came from an exposed Firebase storage bucket: 72,000 images including selfies and government IDs, then over 1.1 million private messages (TechCrunch, July 29, 2025). Claims that Tea was AI-built are unverified, and we do not repeat them. It is here because the mechanism is identical.

Red Access, May 2026. Of 380,000 public assets on AI app-building platforms, roughly 5,000 looked corporate and more than 2,000 held sensitive data, often with admin access for anyone who had the URL.

Before: The browser holds a key that reaches every table or bucket. RLS is off, or on with a policy that says true. The app works because nothing says no.

After: The browser key reaches only rows its user owns: RLS on every table, policies that name auth.uid(), private buckets, and a test that fails the build if a logged-out read returns anything.

Our six Lovable checks walk through the Supabase side of this in under an hour.

2. Auth that trusts what anyone can see

Base44, July 2025. Wiz reported on July 9 that Base44's auth/register and verify-otp endpoints were "exposed without authentication, allowing anyone to register for private applications using only the app_id value," and the app_id sits in every app's URL. Wix fixed it within a day and said it "found no evidence that any customer was impacted."

The lesson generalizes beyond one platform. AI-generated code tends to check that a request is well-formed, not who sent it. Any route that accepts a tenant id, user id or app id from the client and acts on it without checking the session is this bug.

3. Agents with the keys to production

Replit and SaaStr, July 2025. During a declared code freeze, Replit's agent deleted the production database behind Jason Lemkin's project, holding data on more than 1,200 executives and over 1,190 companies, then said rollback was impossible, which was false. Lemkin told The Register he had told it "eleven times in ALL CAPS" not to. Replit's CEO responded with automatic separation of development and production databases.

Amazon Q, July 2025. An attacker used "an inappropriately scoped GitHub token" in AWS's CodeBuild configuration to get a prompt instructing the agent to wipe local files and cloud resources into version 1.84.0 of the VS Code extension. It "was unsuccessful in executing due to a syntax error." Luck, not design.

The pattern behind both

An instruction is not a permission. If an agent, a CI job, or a preview environment holds a credential that can write to production, assume it eventually will. The fix is a credential boundary, not a better prompt.

The three tests that cover all seven

Logged-out read

Open a private window, take the public key from your bundle, and query every table and bucket. Anything returned is finding one.

URL-id action

Using only ids visible in URLs, try to register, read, or write in a space you do not own. Every route should check the session, not the id.

Credential inventory

List every token held by your AI tools, CI, and preview environments. None should be able to write to production.

The one thing to do today

Run test 1. It takes ten minutes, it covers four of the seven incidents, and it is the first thing a security reviewer or an investor's engineer will try.

When this list becomes your problem

Most founders meet these failures at one of five moments: an enterprise pilot sends a security questionnaire, an investor starts technical due diligence, a first engineering hire asks how auth works, an incident lands, or real load arrives. Each of them asks the same three questions this list does. Having the answers dated and written down is the difference between a finding and a footnote.

The failures are not exotic, and the fixes are not a rebuild. Moltbook was patched in about three hours. What takes longer is knowing where to look, which is the part a senior review of the five common patterns shortens.

If you want those three tests run on your actual app by a senior architect, that is what the free teardown is: three findings and a verdict, recorded, within 72 hours.

Sources

Matt Palmer, CVE-2025-48757 and statement, May 29, 2025
Fortune, AI coding tool Replit wiped database, called it a catastrophic failure, July 23, 2025
The Register, Vibe coding service Replit deleted production database, July 21, 2025
AWS, Security Bulletin AWS-2025-015, CVE-2025-8217, July 23, 2025, updated July 25, 2025
Engadget, Tea app suffers breach, July 25, 2025
TechCrunch, Tea app's data breach gets much worse, July 29, 2025
Wiz, Critical vulnerability in Base44, July 29, 2025
Wiz, Exposed Moltbook database reveals millions of API keys, February 2, 2026
Red Access in The Hacker News, What 2,000 exposed apps reveal, May 29, 2026

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

Is my AI-built codebase well designed? Count the files each change touches (2026)

Dan-Cristian Podina — Tue, 01 Sep 2026 14:46:31 +0000

Originally published at systemtrails.com.

Count how many files each small change touches. That number, already in your git history, is the one design signal a non-engineer can read without reading code: if a one-sentence change (rename a field, change a price, add a column) touches three or four files, the parts of your app are still separable; if it touches fifteen, everything is wired to everything, and every future change costs more. Lines of code tell you how much was written. Files per change tells you how well.

In short

The measurement, why it works, and what to do with it:

Run git log --shortstat on the last ten changes and read the "files changed" number
Three or four per small change: parts are separable. Ten or more, routinely: tangled
It is the artifact, not the agent: the one number a coding tool cannot grade for itself
Research since 1998 ties files that change together to design decay and to defects
AI-built code trends the wrong way: duplication up, refactoring down (GitClear, January 2026)
High number is a fix pass, not a rebuild: consolidate one feature at a time

The question, and why "lines" cannot answer it

A founder building an agentic app asked his network in public this summer: can an AI-built app be well architected, and how would a non-engineer know? He could inspect tests, modules and latency, but every inspection meant asking an agent to grade its own homework.

The answer is a measurement of the artifact, not a report from the agent. Lines of code fail because AI tools inflate them. GitClear's Maintainability Gap study, January 2026, across 623 million changes, found duplicated lines per thousand changes rose from 40.3 in 2023 to 73.0 in 2026, moved (refactored) code fell from 21% of changed lines in 2022 to 3.8%, and cross-file function calls dropped 35%. A codebase can triple in size and get worse.

Files touched per change captures what those trends do to you: when logic is duplicated, one business change has to be made in every copy.

The measurement

If the app is on Lovable, Replit or Bolt, connect or export the project to GitHub first; the history is then a terminal command away. Four numbers are worth reading, and none requires understanding the code.

Files per change

git log --shortstat -20 prints one "N files changed" line per commit. Read the N for changes that were small in business terms. This is the headline number.

The file in every commit

git log --name-only --pretty=format: | sort | uniq -c | sort -rn | head lists the most-changed files. One file at the top of every commit is the God File from the five patterns.

Files that travel together

Two files that appear in the same commits 70% of the time have a dependency nobody drew. CodeScene calls this temporal coupling and reports it as a percentage.

Lines per change

Google's guide calls 100 lines a reasonable change and 1,000 usually too large. GitGuardian found Claude Code commits are often twice the size of human-only ones, which is where secrets slip in.

Why this number has held up since 1998

John Ousterhout named the symptom in A Philosophy of Software Design: change amplification, when "a seemingly simple change requires code modifications in many different places".

The research is older than the book. Gall, Hajek and Jazayeri showed in 1998 that release history alone, across 20 releases of a telecom switching system, reveals logical coupling between modules that the source code does not declare, and that this coupling points to structural shortcomings. D'Ambros, Lanza and Robbes followed in 2009 by testing, on three large systems, whether change coupling correlates with defects and whether it improves bug prediction models.

CodeScene turned it into a product: it flags file pairs by the percentage of commits in which they change together, requires at least 10 commits before trusting the trend, and ignores any commit touching more than 50 files so a one-time reorganization does not count. That last rule is also your caveat: one big cleanup commit is fine; ten routine commits that each touch fifteen files are the signal.

What the number looks like in an AI-built app

Before: 14 files changed: the price is a literal in the pricing page, the checkout, the email template, two Edge Functions, the admin table, the marketing banner, and seven tests that each hardcode $49. Miss one and customers see two prices.

After: 2 files changed: one config entry and one test. Every screen and function reads the price from the same place. A new hire ships this on day one without asking anyone.

The first version is what an AI tool produces when each feature was requested in a separate session: it re-creates what it needs rather than reusing what exists, the copy-paste-over-refactor shift GitClear measured.

What you see in git	What it usually means	What to ask
Small changes touch 10+ files	the same logic lives in several copies	"Which single file should own this?"
One file in almost every commit	one file runs everything	"What does this file not do?"
Two files always change together	an undeclared dependency	"Why does A need to know about B?"
Commits of 1,000+ lines for small features	generated in bulk, never reviewed	"What in here is not needed for this feature?"
A change touches only tests, then only code	the tests describe the app's promises	good sign, keep it

The number does not tell you what to fix. It tells you where to look, and whether it is getting better. Run it again after each fix pass; it should fall.

When this number decides something

The five trigger moments each ask this question in their own words. An investor's engineer in technical due diligence checks maintainability by exactly this signal. A first hire experiences it directly: a fifteen-file change on day three is why they leave in month two. An enterprise buyer's security review asks how a fix would be rolled out without touching payment code. After an incident, the fix that touched twelve files is the fix that introduced the second incident. Under load, the file in every commit is the one that cannot be scaled independently.

The one thing to do today

Open a terminal in the repo (or in the GitHub codespace) and run git log --shortstat -10. Write down the ten "files changed" numbers next to a one-line description of what each change was for. If most small changes sit at three or four, keep building. If they sit at ten or more, that list is the first page of your fix plan, and the cost of the pass is now easier to estimate.

What to do with a high number

Nothing drastic. The fix is consolidation, one feature at a time: pick the change that touched the most files, ask which single file should own the logic, move it there, and delete the copies. This is a two to three week fix pass on most AI-built apps, and the trail it leaves, one place per fact and a test that proves it, is what your first hire inherits.

If you would like a senior architect to read your last ten changes and say where the tangle is, that is what the free teardown does: three findings and a verdict, recorded, within 72 hours.

Sources

GitClear, The Maintainability Gap: 2026 AI Code Quality Research, January 2026 (623M changes; duplication 40.3 to 73.0 per thousand changes; moved code 21% to 3.8%; cross-file calls down 35%)
GitClear, AI Copilot Code Quality: 2025 research, January 2025 (211M lines; copy/paste exceeded moved code for the first time in 2024)
GitGuardian, The State of Secrets Sprawl 2026, March 2026 (Claude Code commits about 2x the lines of human-only commits)
John Ousterhout, A Philosophy of Software Design, change amplification as summarized on Wikiversity
Gall, Hajek, Jazayeri, Detection of Logical Coupling Based on Product Release History, ICSM 1998
D'Ambros, Lanza, Robbes, On the Relationship Between Change Coupling and Software Defects, WCRE 2009
CodeScene docs, Temporal Coupling, version 3.4.0, accessed August 31, 2026
Google engineering practices, Small CLs, accessed August 31, 2026

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

What does it cost to make an AI-built app production-ready in 2026?

Dan-Cristian Podina — Tue, 01 Sep 2026 14:46:29 +0000

Originally published at systemtrails.com.

In 2026, making a working AI-built app production-ready costs three things: a diagnosis, which runs from $0 to about $1,500; a fixed-scope fix pass of two to three weeks, which the market prices between $2,500 and $8,000; and, if you keep a senior architect around, a retainer between $2,000 and $15,000 a month. A rebuild is quoted at $5,000 to $30,000 and is almost never the right purchase for an app that already has users.

In short

The 2026 price sheet for making an AI-built app hold, with sources dated below:

Diagnosis: $0 (SystemTrails teardown, 72 hours) to $199 scans to $1,500 full reviews
Fix pass: $2,500 to $8,000 fixed, two to three weeks; freelancer invoices average about $7,200
Senior oversight: $2,000 (SystemTrails) to $15,000 a month; fractional CTO median far above
Rebuild: $5,000 to $30,000, and usually the wrong verdict
Hourly instead: senior US freelancers at $95 to $150 an hour, with the estimate risk on you
Why now: demand for Claude Code specialists up 938% in six months, 2,000+ apps found leaking

Why this price list exists now

Three dated facts explain the market. Fiverr's Business Trends Index, published June 9, 2026, shows searches for Claude Code specialists up 938% between November 2025 and April 2026, with "vibe coding" up 61%. Red Access, May 29, 2026, scanned 380,000 public assets on vibe-coding platforms and found 2,000+ holding sensitive corporate or personal data. And GitGuardian's State of Secrets Sprawl 2026 counted 29 million new hardcoded secrets on public GitHub in 2025, up 34%, with commits co-authored by Claude Code leaking at 3.2% against a 1.5% human baseline.

More people built more, and more of it is now reaching the moment where it has to hold. That moment has five shapes: an enterprise pilot with a security questionnaire, an investor's due diligence, a first engineering hire, an incident, or real load. Each one turns "it works" into a budget line.

The three purchases

Diagnosis

Someone senior reads the code and tells you what is wrong, in what order. Market: $199 fixed-fee scans (Valletta, 48 hours), $500 quick checks, $1,500 full reviews (vibecoding.app, March 24, 2026). SystemTrails: $0, recorded, within 72 hours, capped at 2 per week.

Fix pass

The findings get fixed and documented. Market: $3,000 to $5,000 for review plus remediation in two to three weeks, $5,000 to $8,000 with architecture fixes and docs; agencies $3,000 to $15,000+. SystemTrails' Hardening Sprint: from $2,500, fixed, quoted after the teardown.

Senior oversight

A named architect stays on to review what the AI ships next. Market: fractional CTO advisory $3,000 to $6,000 a month, embedded $8,000 to $15,000 (Groovyweb, April 30, 2026). SystemTrails' Senior Oversight Retainer: $2,000 a month.

The 2026 numbers side by side

What you buy	Market range, 2026	Source and date	SystemTrails
Scan with report	from $199, findings in 48 hours	Valletta, page current July 2026	Free teardown, 72 hours
Quick security check	$500, 1 to 3 days	vibecoding.app, March 24, 2026	included in the teardown
Full review with priorities	$1,500, 5 to 7 business days	same	Free teardown: 3 ranked findings plus verdict
Review plus hands-on fixes	$3,000 to $5,000, 2 to 3 weeks	same	Hardening Sprint from $2,500
Cleanup with architecture and docs	$5,000 to $8,000, 3 to 6 weeks	same	Hardening Sprint, scoped after teardown
Senior agency, 12-page report, 18 checks	from $2,500	Beesoul via vibecoding.app roundup, 2026	comparable tier
Enterprise security firm	$8,000 to $15,000+	vibecoding.app, March 24, 2026	not the same product
Rebuild	$5,000 to $30,000	HatchWorks, April 13, 2026	we do not pitch rebuilds
Fractional CTO, advisory	$3,000 to $6,000 a month	Groovyweb, April 30, 2026	Retainer $2,000 a month
Fractional CTO, embedded	$8,000 to $15,000 a month	same	Retainer $2,000 a month
Senior US freelancer	$95 to $150 an hour	Arc, May 26, 2026	fixed prices only

The same March 2026 pricing guide puts the typical solo founder spend at $1,500 to $5,000 and the average completed freelancer invoice for a full project at about $7,200. Read those two numbers together: the founder who buys a scan and then fixes things one at a time often ends up at the higher figure.

What moves the price inside the range

The quote for a fix pass depends on what the teardown finds, not on the size of the app. Four things move it.

Secrets and keys

A leaked Supabase secret key or Stripe key means rotation, an incident note, and a search of the git history. Cheap to do, expensive to skip. The Lovable pre-launch checks cover the 60-second test.

Data isolation

Missing or permissive row-level security across many tables is the single largest line item, because each policy has to be read against what the product actually promises.

Structure

One giant file and no tests raise the cost of every other fix, since nothing can be changed safely until the first tests exist. This is where the "3x technical debt rate" HatchWorks cites for ungoverned AI development shows up as hours.

Evidence required

A security questionnaire or a due-diligence data room needs written artifacts: architecture map, restore log, dependency scan. Producing them is part of the pass, not an extra.

Fixed price or hourly

Before: $95 to $150 an hour. Estimating a hardening pass on code nobody has read is guesswork, so the overrun is yours. 20 hours becomes 60, and the first invoice arrives before the first finding.

After: The person quoting has already recorded a walkthrough of your code. The number is published, the scope is written, and the deliverable includes the trail: tests, runbook, map. Overruns are the architect's problem.

The teardown exists so the fixed price is honest. A scope written before anyone has seen the code is either padded or wrong.

Where the money goes by trigger

Each trigger moment buys a different slice of the same work. An enterprise pilot needs the questionnaire answered with evidence in weeks, so the fix pass front-loads security and the documents. Due diligence needs the five things a 2026 reviewer asks for, and investors can buy their own read at $1,500. A first hire needs the map and the tests, or the hire leaves. An incident needs the key rotated today and the cause fixed this week. Scale pain needs the smallest performance pass that makes the app hold at ten times the load.

The one thing to do today

Do not buy a fix pass from anyone who has not seen the code. Get a diagnosis with a written fix-or-rebuild verdict first; the market prices that at $0 to $1,500 and it takes days, not weeks. If the verdict says rebuild, ask for the specific requirement the current platform cannot meet. If nobody can name one, it is a fix.

What "production-ready" buys you

The money is not spent on making the app work; it already works. It is spent on making it hold when someone else looks: the buyer's security team, the investor's engineer, your first hire, or the traffic spike. The trail they find, tests, policies, a restore date, a map, is what the price above pays for.

If you want the diagnosis first, the free teardown is three ranked findings and a fix-or-rebuild verdict, recorded, within 72 hours.

Sources

Fiverr, Business Trends Index: Businesses Race to Hire Claude Code Specialists As Demand Surges 938%, June 9, 2026
The Hacker News on Red Access, "The Shadow Builders", May 29, 2026
GitGuardian, The State of Secrets Sprawl 2026, March 2026
vibecoding.app, Vibe Code Cleanup Cost: Real Pricing for 2026, March 24, 2026
vibecoding.app, Best Vibe Code Audit Agencies (2026), 2026 (Beesoul: from $2,500, 18 checks, 8 to 14 issues per app)
Valletta Software, Vibe Coding Audit, page references July 2026 (from $199, 48 hours, remediation 6 to 8 weeks typical)
HatchWorks, The Real Cost of Vibe Coding in 2026, April 13, 2026
Groovyweb, Fractional CTO Cost in 2026, April 30, 2026
Arc, Freelance Developer Rates in 2026, May 26, 2026
SystemTrails prices: pricing page, current August 31, 2026

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

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.