Is Your AI-Built App Production-Ready? A 12-Gate Audit

An AI-built application is not production-ready because the demo works, the interface looks finished or the build is green. It is ready for a particular release only when the team can produce evidence that the product is owned, reproducible, authorized correctly, recoverable and operable under the failures that matter to the business.

This article gives you a first-pass audit organized around twelve evidence gates. Each gate ends in one of three states:

• PASS — the required artifact or rehearsal exists and matches the system you plan to release;
• FAIL — evidence proves that a material control or operating capability is missing;
• NOT VERIFIED — the answer may be good, but nobody has produced relevant evidence yet.

Do not calculate a percentage score. A product with eleven green gates and one cross-tenant data leak is not “92% production-ready.” One failed release blocker can make the verdict NO-GO. Several unknowns can make it NOT ENOUGH EVIDENCE.

Download the 12-Gate Production Audit Worksheet before you start. Record the exact repository revision, environment, evidence link, business impact, owner and verification date for every result. Never put secret values or raw customer data in the sheet.

The objective is not twelve reassuring answers. It is twelve explicit evidence states tied to one release and environment.

Before you run anything: protect the system you are auditing

The commands below are examples, not a universal script. First identify the actual languages, package manager, hosting model and deployable surfaces. Then follow four safety rules:

1. Work only on systems you own or are explicitly authorized to test. Do not probe another customer's data to test authorization.
2. Use a disposable clone or isolated container without production credentials. Package installation and project scripts can execute code.
3. Prefer read-only inspection before builds, migrations or active tests. Never run a migration, restore, load test, exploit scanner or “test commit” against production as part of this checklist.
4. Keep evidence controlled. Secret-scanner reports, logs, database samples and configuration inventories may be sensitive. Do not paste proprietary code, tokens or customer data into a public AI chat or unknown scanning service.

This is a triage audit, not a penetration test, privacy review, legal assessment or production acceptance. NIST's Secure Software Development Framework provides a common secure-development vocabulary, while OWASP ASVS 5.0.0 provides a much broader set of testable web-application security requirements. Twelve gates cannot replace either framework.

What current evidence says about AI-authored code

The useful conclusion is narrower than “AI code is bad.”

A 2026 preprint, Debt Behind the AI Boom, analyzed 302,579 explicitly AI-attributed commits across 6,299 public GitHub repositories. Its static-analysis pipeline identified 484,366 introduced findings: 89.3% code smells, 6.0% correctness findings and 4.7% security patterns. Of the findings the researchers could track, 22.7% were still present at the repository's latest revision. AI-attributed commits fixed slightly more code smells than they introduced, but introduced about 1.5 times as many security findings as they fixed.

Those numbers have important limits. The sample covers popular public repositories, Python/JavaScript/TypeScript and only commits with visible AI attribution. It does not provide a clean human-only baseline. The findings come from static analysis and are not automatically exploitable vulnerabilities. Use the study to choose where to look—not to estimate the probability that your application is insecure.

A separate GitClear vendor report describes observational trends across 623 million code changes from 2023–2026: block duplication up 81%, refactoring line moves down 70% and error-masking changes up 47%. This is vendor-authored, observational evidence; it does not prove that AI alone caused every trend. It does support checking duplicated business logic and suppressed errors rather than assuming that continued feature generation will clean them up.

AI authorship is therefore a risk signal, not a defect. The gates below apply to human-written software too.

Gate 1 — Ownership and operating authority

Production promise: the company can operate the product without the original builder's personal account, laptop or memory.

Record the exact owner and at least two client-controlled administrators where the provider supports it for source control, hosting/cloud, domain and DNS, database, email delivery, app stores, payments, monitoring and critical SaaS integrations. Include billing ownership, recovery identity, machine accounts and the person authorized to stop or approve a production change.

Safe repository checks:

git remote -v
git branch --all
git log -n 20 --decorate --oneline

These commands show repository context. They do not prove that the business owns the organization, the deployed environment or the recovery path.

PASS evidence: provider/account IDs, named administrators, independent recovery route, billing owner, machine-identity inventory and a tested escalation path.

FAIL examples: production exists only inside a builder's personal workspace; nobody at the company can stop deployments; the only recovery method is the former developer's phone.

NOT VERIFIED: “the founder pays the invoice” or “we have the GitHub URL” without provider-level ownership evidence.

If access itself is missing, pause this audit and use the first-72-hours access-recovery runbook. You cannot safely evaluate or change a system you do not control.

Gate 2 — Source provenance and reproducible build

Production promise: the repository you are reviewing can be traced to the workload customers actually use.

Capture the revision and working-tree state:

git rev-parse HEAD
git status --short
git ls-files | rg '(^|/)(package-lock.json|pnpm-lock.yaml|yarn.lock|poetry.lock|uv.lock|requirements.txt)$'
npm pkg get scripts

For an npm project, npm ci requires the lockfile to match package.json, does not rewrite either file and replaces the clone's existing node_modules. It can still execute dependency and project lifecycle scripts. Start inside a disposable environment without credentials:

npm ci --ignore-scripts
npm run build

Some legitimate packages need install scripts, so that first build may fail. If it does, review the declared scripts and package sources, then run the normal install only in the isolated environment. Do not turn off safeguards on a credentialed workstation merely to get a green build.

PASS evidence: authoritative repository and history, one package-manager/lockfile path, documented environment-variable names, clean build output and a trace from commit → build run → immutable artifact → deployment revision.

FAIL examples: only a ZIP exists; the deployed revision cannot be identified; the build depends on undeclared files or one person's browser workspace.

NOT VERIFIED: “it builds on the original machine” without an independent clean build and production provenance.

Gate 3 — Authentication and object-level authorization

Production promise: signing in proves identity, and every sensitive action independently verifies what that identity may do to this exact object.

Create two authorized test accounts in a staging or dedicated test tenant. Give each account its own project, document, order or other protected object. Build a small matrix:

Use identifiers from the controlled test accounts—not guessed production IDs. Check the API response and resulting data, not only whether the UI hid a button. OWASP classifies missing per-object checks as Broken Object Level Authorization and recommends authorization checks in every function that uses client input to access a record. Its testing guide likewise uses multiple controlled users and objects.

Authentication opens a session. Authorization must still be proven for each tenant, object, action and sensitive field.

PASS evidence: an authorization matrix, repeatable negative tests at the API/data boundary and server-side checks covering read, create, update, delete, export and administrative actions.

FAIL: either test user can read or modify the other's protected object; an admin-only action relies on client-side visibility; changing a tenant ID changes authority.

NOT VERIFIED: login works, but no cross-account negative test exists.

Treat a failed cross-tenant test as a release blocker and possible incident. Preserve relevant logs, contain the affected path and involve the security, business and qualified legal owners. This article cannot decide whether notification is legally required.

Gate 4 — Secrets and privileged access

Production promise: credentials are not embedded in source, history, client bundles, logs or shared documents, and exposed values can be rotated without losing the service.

GitHub states that its secret scanning covers Git history across all branches for supported secret types. For a local first pass, install a reviewed, pinned version of a scanner from its official distribution and keep output access-controlled. Current Gitleaks syntax supports redaction:

gitleaks git --redact --no-banner .

Do not replace this with a broad grep that prints possible secrets into terminal history or a shared CI log. A scanner finding still needs validation; a clean scan still needs an inventory of runtime secrets, client-exposed configuration, deploy keys, webhook secrets and machine identities.

PASS evidence: redacted history-scan result, managed secret locations, classification of public versus privileged keys, rotation owner and date, and proof that client bundles/logging do not contain privileged values.

FAIL: a live credential appears in Git history or the browser; a service-role/admin key is shipped to the client; production depends on an unowned personal token.

If it fails: contain and rotate the credential first, then decide whether history rewriting is required. Deleting a line from the latest commit does not revoke the value.

Gate 5 — Dependency and supply-chain control

Production promise: the team knows what third-party code enters the build, which versions ship and who responds to a vulnerable or malicious release.

Start with manifests and the authoritative lockfile. For npm, a non-mutating advisory query is:

npm audit --omit=dev
npm ls --all

npm audit sends package names and versions to the configured registry and covers known advisories, not every malicious or unsafe behavior. Do not run npm audit fix, automated major upgrades or an unreviewed npx command as part of evidence collection.

GitHub's dependency graph can show direct and supported transitive dependencies, versions, licenses and known vulnerabilities. It can also export an SPDX SBOM. An SBOM is inventory, not proof that every package is safe.

Install scripts deserve explicit review. npm documents that npm ci may run preinstall, install, postinstall, prepare and related lifecycle operations. GitHub's July 2026 supply-chain hardening summary explains why attackers target install-time scripts and stolen publishing credentials.

PASS evidence: lockfile/SBOM tied to the release, approved package sources, install-script review, license/support status, known-vulnerability triage and a named response owner.

FAIL: unpinned remote tarballs or Git dependencies with no provenance; a critical exploitable production advisory without mitigation; a dependency nobody can explain that executes during install.

NOT VERIFIED: npm audit is green but the shipped artifact, transitive tree or install behavior is unknown.

Gate 6 — Data model, migrations and integrity

Production promise: the application preserves the business facts it is supposed to store across concurrent use, schema changes and recovery.

Map the core entities, stable identifiers, tenant/owner fields, lifecycle states and business constraints. Compare three things without changing production:

repository migration history → production migration ledger → actual production schema

Then identify manual SQL, generated schemas, builder-managed changes and backfills that exist outside the repository. A migration folder is not authoritative if production was changed through a dashboard and nobody reconciled the difference.

Choose a few invariants that would matter during an incident or acquisition: an order total equals its lines, a document belongs to one tenant, a payment event is applied once, a deleted account follows the stated retention behavior. Test them on controlled data and at boundary conditions.

PASS evidence: schema/provenance comparison, migration ledger, constraints, versioned backfill plan, forward/rollback or compensation strategy and verified business invariants.

FAIL: tenant ownership exists only in UI state; production schema differs from the repository; a retry can duplicate money, email or another irreversible result.

NOT VERIFIED: tables look reasonable in a dashboard but there is no migration or integrity evidence.

Gate 7 — Failure handling and external integrations

Production promise: a slow, duplicated, rejected or out-of-order external event does not become lost data, false success or an unlimited bill.

Inventory every payment, email, storage, model API, webhook, queue and scheduled job. For each, record timeout, retry policy, idempotency/deduplication key, terminal failure state, reconciliation path, variable cost and owner.

Code search can locate review targets, but it cannot prove behavior:

rg -n 'fetch\(|axios\.|requests\.|timeout|retry|idempot' . \
  --glob '!node_modules/**' --glob '!dist/**' --glob '!build/**'

In staging, exercise at least one provider timeout, duplicate callback and rejected request. For an operation with an external side effect, also consider the crash window after the provider succeeds but before the local database records completion.

PASS evidence: bounded timeouts/retries, idempotent business result, visible pending/failed/uncertain states, reconciliation and a tested manual recovery path.

FAIL: the UI reports success before durable acceptance; retries duplicate a charge or email; a user-controlled loop can generate unbounded LLM/API cost.

NOT VERIFIED: the integration worked once on the happy path.

Gate 8 — Privacy, logging and data exposure

Production promise: the product collects only intended data, sends it only to known processors and does not leak it through logs, analytics, URLs or AI tooling.

Create a data-flow inventory from input to database, files, email/CRM, analytics, logs, backups, model providers and support tools. Record purpose, owner, retention/deletion behavior and access boundary. Review sanitized test-account logs and telemetry—not a broad export of production customer data.

CISA's Secure by Demand guide emphasizes customer-accessible security logs and software-supply-chain provenance. Useful logs still need minimization, redaction, access control, retention and an owner.

PASS evidence: current data/processor map, least-data decision, redaction tests, access/retention rules, customer deletion/correction path where applicable and no secret or sensitive payload in generic telemetry.

FAIL: tokens or message bodies enter analytics; private uploads are publicly addressable; an AI tool receives production customer data without an approved data-flow decision.

NOT VERIFIED: a privacy policy exists but nobody compared it with actual network and storage behavior.

This gate is engineering evidence, not a legal-compliance verdict. US state, sector, contractual and international-transfer requirements depend on the real data and business role.

Gate 9 — Observability and actionable alerts

Production promise: when a core flow fails, the team can identify the affected release, request and business outcome, and the right person is notified.

An uptime dashboard is not enough. A service may return 200 OK while losing form submissions or applying the wrong tenant filter. At minimum, connect errors and critical business outcomes to a release identifier, environment and bounded correlation ID. Avoid customer content and unbounded high-cardinality identifiers in telemetry.

OpenTelemetry's observability primer distinguishes logs, metrics and traces and notes that reliability is about what users expect the service to do—not uptime alone. The implementation can use any suitable stack; the evidence requirement remains the same.

PASS evidence: release markers, server and browser error capture, critical-flow metrics, alert rules, recipients/escalation, retention and a successful test alert acknowledged by the named owner.

FAIL: errors exist only in a browser console; alerts route to the departed builder; backup, queue or payment failures have no signal.

NOT VERIFIED: a monitoring SDK is installed but no one has triggered and acknowledged a representative alert.

Gate 10 — Recovery proven by an isolated restore

Production promise: the product can recover its critical business state after deletion, corruption, provider loss or a bad release.

“Backups enabled” is not evidence of recovery. Restore a recent, identified backup into an isolated target with external email, payment, webhook and notification effects disabled. Include the database, object/file storage and the configuration or control-plane material needed to make the restored system meaningful.

Record:

• backup timestamp and the expected recovery point;
• restore start/end time and operator;
• dataset, object and configuration coverage;
• row/object counts and selected business invariants;
• missing or inconsistent cross-system effects;
• actual recovery time and the stated recovery expectation.

NIST contingency guidance treats backup restoration as a system test, with explicit objectives and success criteria.

PASS evidence: independently completed isolated restore, measured result, business-integrity checks and a repeatable runbook.

FAIL: the only backup is inside the same failed account; restore cannot recover critical files/data; the test would send real customer effects.

NOT VERIFIED: the provider reports successful backup jobs but no restore has been exercised.

Recovery and release are rehearsals, not configuration checkboxes.

Gate 11 — Release provenance and rollback

Production promise: the team can release a small change from known source, observe it and return to a safe state without guessing.

Map every production trigger: branch push, tag, manual dispatch, builder publish button, provider auto-deploy, cross-repository workflow, GitOps sync, migration and scheduled job. Do not push a “test commit” until you know which of those paths it activates.

For one controlled release, capture:

commit SHA → CI run → artifact/image digest → deployment ID → migration state → smoke result → observation window → rollback decision

Rollback is not always “deploy the old version.” A backward-incompatible migration, external notification or payment cannot be undone by restoring code. Define compatibility, compensation and kill boundaries for those effects.

PASS evidence: reproducible artifact, protected/approved release path, environment separation, tested smoke checks, observation thresholds and a rehearsed rollback or forward-recovery plan.

FAIL: merging directly deploys unknown side effects; production was built from an untraceable snapshot; nobody can stop or reverse the release path.

NOT VERIFIED: the platform has a rollback button but the team has never used it with the application's schema and integrations.

Gate 12 — Critical-path verification and operating ownership

Production promise: the business-critical journey works end to end, failure is supportable and variable usage cannot silently become an operational or cost incident.

Define the smallest set of flows whose failure would invalidate the release: signup/authentication, tenant isolation, core create/update workflow, payment or booking, customer notification, export, administrative recovery. Test real outcomes, not component rendering alone. Include failure, repeated action, expired permission and concurrency where relevant.

For products that call model APIs, also record per-user and account quotas, timeout/fallback behavior, billing alerts, model/provider version ownership, sensitive-input policy and what happens when output is malformed or unavailable. A polished generated answer is not proof of a completed business action.

PASS evidence: critical-path tests in CI, production-like smoke evidence, explicit scale/cost horizon, incident route, support hours, dependency owners and a new person able to follow the runbook.

FAIL: the green suite asserts only that components render; no one owns incidents; user-controlled work can create unbounded cost; the core result cannot be reconciled after partial failure.

NOT VERIFIED: the founder can demo the flow but no repeatable evidence ties input to durable business result.

Platform branches: use only the ones that apply

Supabase or browser-to-database products

Supabase's current RLS guidance explains that grants decide which operations a role may perform and policies decide which rows the operation reaches. Enable and test both on every exposed table. Its API-key documentation distinguishes publishable/legacy anon keys—which are expected in clients when RLS and least privilege are correct—from secret/legacy service_role keys, which bypass RLS and must stay server-side.

Do not mark this branch passed because “RLS is on.” Use two controlled users and verify select, insert, update, delete, RPC/function and storage behavior. A permissive policy can make an enabled control ineffective.

Lovable, Bolt, Replit and hosted builders

Verify what can be exported, whether repository history is complete, who owns the builder/hosting account, how environment variables and database migrations are represented, which background jobs or provider integrations exist and how the deployed revision maps back to source. Do not assume platform hosting makes application authorization, data rules or recovery correct.

Cursor, Claude Code and repository agents

Review agent instructions, generated workflows, machine identities, allowed tools and production access. AI provenance can help focus review, but absence of an AI trailer does not prove human authorship, and presence of one does not prove a defect.

Turn the worksheet into a release decision

For every gate, record:

Use four first-pass verdicts:

• NO-GO — a P0 exists: confirmed unauthorized cross-tenant access, exposed privileged credentials, unknown production provenance, unrecoverable critical data or no authority to control production change.
• GO WITH CONDITIONS — no P0 remains, but bounded P1/P2 risks have explicit owners, mitigations, dates and an authorized release decision.
• NOT ENOUGH EVIDENCE — critical gates remain not verified. This is not a softer form of GO.
• READY FOR THE NEXT ASSURANCE STEP — the twelve gates have relevant evidence, so the product can proceed to the project-specific security, privacy, performance, sector and release checks it actually requires.

The last label is intentionally not “certified production-ready.” A healthcare workflow, marketplace, financial product, children's service or enterprise deployment needs additional controls and qualified review.

When this audit is being performed because a prospective customer sent a vendor assessment, use the enterprise security questionnaire evidence model to translate findings into scoped statements, disclosure-safe evidence and explicitly approved gaps. A production audit result should not be pasted into a buyer questionnaire without checking the customer's service boundary and the exact claim.

Do not decide to rewrite based on the number of failed gates. Authorization, migrations, recovery and duplicated business rules may require structural work; other findings may be contained changes. First establish the verified source and production behavior, then compare repair, staged replacement and rebuild options with migration and rollback costs included.

The rewrite, refactor or replatform decision model provides that comparison. It records critical behavior, boundaries, custody, platform viability, data migration, business change and disruption as an evidence profile, with UNKNOWN kept separate from a confirmed defect.

If this application is being reviewed as part of an acquisition, continue with the small-SaaS technical due diligence guide. It adds rights and license evidence, provider economics, customer promises and transition dependencies that a production-readiness audit does not decide.

If the app is accessible but needs an accountable assessment and remediation sequence, H Product Studio's AI Code Rescue starts with graded findings and a prioritized plan. If another supplier is handing over a live product, continue with the 30-day software project takeover checklist. A stable product that mainly needs ongoing releases may fit application maintenance; architecture constraints that block the roadmap may justify application modernization after the baseline is proven.

Frequently asked questions

How long does this audit take?

You can start the inventory and run the read-only checks in one focused session if the repository and provider accounts are accessible. You cannot honestly finish authorization, restore, release and rollback gates in a fixed number of minutes unless those rehearsals and records already exist. Time spent uncovering a missing build or recovery path is part of the result, not a delay in the audit.

Can a non-technical founder use it?

Yes, as the evidence owner. A founder can verify account ownership, request a restore demonstration, confirm who receives alerts and insist on a written release/rollback record. An engineer should run code, dependency and controlled authorization tests. A qualified security or legal professional is needed when the evidence points to exposure, regulated data or notification questions.

Does it matter whether AI wrote the code?

Only as a prior and a review-routing signal. The same gates apply to human-written software. AI-assisted workflows can produce high change volume and locally convincing happy paths, so provenance, authorization, duplication, suppressed errors and dependencies deserve early attention.

If all twelve gates pass, can we launch?

Passing means you have evidence against these common blockers. It does not answer every project-specific question about threat model, accessibility, privacy, sector rules, scale, support coverage or client acceptance. Use the result to move into the narrower release review your product requires.

What should we do after an authorization or secret failure?

Stop the affected release or path, preserve relevant evidence, contain access and rotate confirmed exposed credentials through the provider's supported process. Name an incident owner and assess the scope before destroying logs or rewriting history. Get qualified advice for legal or contractual notification decisions.

Should we ask the AI tool to fix every finding?

AI can help implement a bounded correction, but it should not approve its own work. Define the expected behavior and negative test first, make a small change, review the diff and verify the result independently in the correct environment.

If the worksheet leaves a release blocker or a material unknown, describe the codebase, hosting model and evidence you already have. Do not send source archives, passwords, production secrets or customer data through the contact form.

Research reviewed on 25 August 2026 against NIST SSDF 1.1, OWASP ASVS 5.0.0 and API Security guidance, CISA Secure by Demand, current GitHub/npm/Supabase documentation, NIST recovery guidance, the scoped 2026 AI-code preprint and the clearly labeled GitClear vendor report. Recheck provider and tool documentation when you act.