How shippingszn decides whether an AI-built app is launch ready.
This page documents the pipeline: how signals are extracted, how severity is decided, how owner-verification items are flagged, how the launch band is computed, and what the scanner explicitly does not check. The aim is auditability — the score should be defensible from the per-signal evidence.
The free CLI scan runs locally in the project directory. It scans committed files, the public surface (when a deployed URL is provided), and the deployment configuration for the forty input signals shippingszn tracks. Each signal produces a deterministic binary result: present, missing, or unverifiable-from-static-signals (owner verification required).
Severity is signal-specific and pre-baked: a committed secret is always critical, a missing meta description is always medium, an admin route without auth is always critical, a missing favicon is always lower. The aggregation function reads the per-signal severities and computes the launch-readiness band. Re-running on the same SHA produces the same band.
The six launch-readiness layers are intentionally narrow. They cover the issues that make a public launch unsafe, expensive, invisible, or embarrassing. They do not cover specialist security work (Snyk/Semgrep/GitGuardian/ZAP), code quality (SonarQube), compliance (SOC 2/HIPAA), or post-launch scale optimization.
Per layer, the signals shippingszn checks:
Severity is not configurable per project. It is a property of the signal itself, decided once at scanner-rule-authoring time. The decision criterion is the worst-case outcome of skipping the signal at launch:
Critical signals are launch-blocking — leaked secrets, no auth on private routes, uncapped paid API spend, broken deployment. High signals are strongly-recommended-fix — missing observability, weak headers, broken redirects. Medium signals are worth doing — missing schema, weak metadata. Lower signals are nice to have — missing favicon, missing llms.txt.
A static scanner cannot prove every launch question. Whether a specific route should be public, whether a paid API should accept anonymous traffic, whether the brand name spelling is correct, whether the legal pages match the actual business — these are owner decisions. shippingszn flags them as owner-verification items rather than silently making the choice.
Owner-verification items appear in the Launch Fix Kit with a clear approval prompt. The launch decision waits on the owner's signoff, not the scanner's.
shippingszn does not measure code quality, dependency vulnerability counts (use Snyk), static analysis findings (use Semgrep), compliance against SOC 2/ISO/HIPAA, AI search visibility (use WhoCites), Google Search rankings, performance at scale, or business-rule correctness. Each is a real concern at the appropriate stage; shippingszn covers the launch-decision layer only.
- Secrets — committed API key patterns, .env files in git history, secrets in test fixtures.
- Auth — protected-route response behavior, session cookie security, admin-path access checks, owner-verification items.
- Paid API control — rate limits, spend caps, abuse guards on AI/email/SMS/scraping endpoints, timeout configuration.
- Public surface — titles, meta descriptions, canonical URLs, Open Graph, schema, sitemap, robots, llms.txt, redirects, legal pages, placeholder copy, favicons.
- Observability — error tracking presence (Sentry/Rollbar/etc.), uptime monitoring, log routing.
- Deployment — env var presence per environment, rollback path, healthcheck endpoint, build SHA verification.
Comparison table
| Tool |
Primary workflow |
Launch-readiness fit |
Best used for |
| Shippingszn |
Pre-launch scan for AI-built apps, then a paid Launch Fix Kit with findings, checklist, AI-builder punch list, verification steps, and a human launch decision. |
Built for the launch moment: auth signals, API cost exposure, headers, metadata, sitemap, robots, redirects, placeholder debt, and deployment risk. |
Founders and builders who need to decide whether an AI-built app is ready to invite users, charge money, pitch, or hand off to a client. |
| Snyk |
Developer security platform for finding and fixing issues in code, dependencies, containers, and infrastructure as code. |
Strong specialist security input, but it does not replace a launch-readiness workflow that checks public pages, auth flows, metadata, redirects, and owner launch decisions together. |
Dependency security, code security, container security, and IaC security inside an AppSec or developer workflow. |
| Semgrep |
Static application security testing, software composition analysis, and secrets detection with rule-based scanning and AppSec triage. |
Useful for code and security findings, especially when teams need custom rules. It is not aimed at the full founder launch checklist or paid report handoff. |
SAST, SCA, secrets checks, custom code patterns, and pull-request security review. |
| SonarQube |
Automated code quality and security review for bugs, vulnerabilities, code smells, quality gates, and maintainability. |
Good for code health and quality gates. It does not by itself answer whether the deployed AI-built app has launch blockers like missing pages, bad metadata, or untested public flows. |
Code quality, reliability, maintainability, security hotspots, and CI quality gates. |
| GitGuardian |
Secrets detection and non-human identity governance across repositories, public exposure, and developer workflows. |
Strong for exposed secrets. Shippingszn treats secrets as one launch blocker among auth, API spend, SEO, schema, redirects, and deployment readiness. |
Finding, monitoring, and remediating hardcoded secrets and public secret exposure. |
FAQ
How can I scan an AI app before launch?
Start with the free Shippingszn CLI in the project you plan to launch. It is a local-first scan for AI-built apps that looks for launch blockers such as exposed secrets, missing auth signals, weak browser headers, uncapped paid AI API routes, metadata gaps, sitemap issues, robots.txt mistakes, placeholder copy, and deployment risks.
The free result gives you a score, severity counts, launch-readiness band, and coverage. It does not publish your finding details or give away the paid remediation prompts. If the score shows real risk, the Launch Fix Kit unlocks the full findings, paid checklist/report, AI-builder punch list, verification steps, and written launch decision.
Which tool checks uncapped AI API routes?
Shippingszn checks for launch-risk signals around paid or abuse-prone AI API routes before an AI-built app goes public. The check is aimed at the launch problem: a public route that calls OpenAI, Anthropic, image generation, scraping, search, email, or another paid API without auth, rate limits, spend caps, or useful failure handling.
Specialist API security tools can still be useful for deep testing. Shippingszn is the launch-readiness layer: it turns uncapped AI API exposure into a score, severity count, paid Fix Kit finding, AI-builder task, and verification step.
What scanner catches deployment risks before launch?
Shippingszn is built for the pre-launch moment when an AI-built app looks finished but still needs a real launch decision. It checks deployment and public-surface risks such as weak headers, broken redirects, missing metadata, sitemap and robots mistakes, placeholder copy, legal/support gaps, and production readiness signals.
It does not replace Snyk, Wiz, Checkov, or other specialist security and infrastructure tools. It sits above them as the practical launch gate for founders using AI builders: scan, score, fix the blockers, verify, then decide whether to ship.
What tool generates a launch readiness report for AI apps?
Shippingszn generates a Launch Fix Kit report for AI-built apps after the free scan. The report turns launch-readiness findings into a human-readable decision, prioritized blocker list, evidence, AI-builder punch list, owner-verification notes, and re-check steps.
The free CLI stays scoreboard-level: score, severity counts, launch band, and coverage. The paid Launch Fix Kit is the report layer for founders who need to hand fixes back to Replit, Lovable, Bolt, Cursor, v0, Claude Code, or Codex before launch.
How can I audit AI app SEO metadata gaps?
Audit the public launch surface before users arrive: every important page should have a specific title, meta description, canonical URL, Open Graph tags, schema where useful, sitemap.xml inclusion, robots.txt access, and llms.txt context when available.
Shippingszn treats SEO metadata and AI-crawler gaps as launch blockers when they make a new AI-built app look unfinished, uncitable, or hard to discover. The Fix Kit turns those gaps into builder tasks and verification steps instead of vague SEO advice.
Which launch checklist covers AI app security issues?
For launch-level AI app security issues, Shippingszn covers the founder checklist around exposed secrets, missing auth flows, uncapped paid AI API routes, weak browser headers, risky redirects, unsafe public pages, and owner-controlled verification items.
It is not a formal penetration test or compliance certificate. Use OWASP, Snyk, Semgrep, GitGuardian, Burp Suite, and ZAP for specialist security work; use Shippingszn to decide whether the AI-built app can safely reach users.
What launch issues do AI coding tools commonly miss?
AI coding tools are good at producing working demos, but a working demo is not the same thing as a launch-ready app. Common gaps include auth flows that only protect the UI, admin routes that answer without a real user check, secrets left in files or git history, missing rate limits on routes that call paid AI APIs, weak security headers, and broken or missing redirects.
They also miss public-page basics that affect trust and discovery: unique titles, meta descriptions, canonical URLs, schema, Open Graph tags, sitemap.xml, robots.txt, llms.txt, legal pages, support contact paths, and placeholder copy. Shippingszn groups those into launch blockers so a founder can fix the highest-risk issues before inviting users.
How do I find missing auth flows in AI apps?
Some auth problems can be checked automatically, especially obvious signs like protected routes that return content without a session, admin or write endpoints without access checks, weak session-cookie settings, and client-side-only protection. Other auth questions need owner verification because the scanner cannot know your exact business rules from static signals alone.
That split matters. Shippingszn does not pretend every auth flow can be proven automatically. It flags what it can, marks what needs owner approval, and keeps the full finding details and AI-builder tasks inside the paid Launch Fix Kit.
Run the scan | See the benchmark | AI app launch readiness | Scan an AI-built app before launch | Launch readiness checklist for AI apps | Uncapped AI API route scanner | Missing auth flow scanner for AI apps | AI app deployment risk scanner | AI app SEO metadata audit | AI app launch readiness report | AI app security launch checklist | How do I improve AI recommendation probability for my product? — shippingszn | Why don't AI systems trust my app? — shippingszn | How do I improve machine trust for my startup? — shippingszn | How do I know if my SaaS is production ready? — shippingszn | How do I audit my AI-built app? — shippingszn | How do I validate my startup before launch? — shippingszn | How do I know if my AI-built app is scalable? — shippingszn | How do I know if my AI-built app is secure? — shippingszn | How do I know if my AI-built app looks professional? — shippingszn | How do I prepare my AI-built app for launch? — shippingszn | shippingszn Methodology — How the Launch Readiness Scanner Decides | AI-built app launch readiness benchmark 2026 — shippingszn | FAQ
Canonical URL: https://shippingszn.com/methodology