DeploiaBeta
Sample launch-readiness report

Launch verdict: do not invite real users yet.

This sample shows the new Deploia pattern: a clear verdict, readable readiness areas, repo-specific evidence, and next actions that tell a builder exactly what to fix before launch.

Repo: acme/nextjs-saas-sampleMode: AI-built SaaS prototypeOutcome: launch safelyConnector: sample data

Overall readiness

57

Blocked until critical gaps are fixed and re-scanned.

4 blockers

Not ready for real users yet.

Do not launch yet

Critical and high-risk issues remain.

The app can become launchable, but authorization, AI guardrails, webhook reliability, and observability need work first.

Evidence required

Unknowns are treated as risk.

The report separates verified facts, inferred risks, and assumptions the user should confirm in the repo.

Actionable output

Fix guidance before remediation.

Each finding explains where Deploia saw it, why users care, and what branch-level change comes next.

Structure

App structure and trust boundaries

82

Mostly ready, confirm the remaining gaps.

Clear Next.js and Supabase shape, but trust boundaries need to be confirmed around privileged routes and data writes.

What to do in this repo

Map the main routes, server actions, data stores, and privileged paths in this repo, then confirm each sensitive path has an owner and boundary.

Access

User access and secret safety

58

Not ready for real users yet.

Authentication exists, but admin actions and webhook protections still need file-level evidence and denial tests.

What to do in this repo

Add role checks around privileged routes, verify webhook signatures, move secrets server-side, and add tests that prove denied access stays denied.

Deploy

Production deploy path

76

Close, but fix the launch blockers first.

Vercel is a good fit, but production env, health checks, and rollback steps should be proven before launch.

What to do in this repo

Confirm the target host, required env vars, build/start commands, health endpoint, release branch, and rollback plan before inviting users.

Observe

Know when production breaks

44

Not ready for real users yet.

The app needs alerting, tracing, health checks, and a named incident owner before customers become the monitoring system.

What to do in this repo

Add a health endpoint, error tracking, request logs, alert routing, and a named owner for the first production incidents.

Data

Data handling and customer trust

61

Close, but fix the launch blockers first.

PII paths are likely, so retention, backups, restore drills, and audit logs need to be defined.

What to do in this repo

Document sensitive fields, retention rules, backup/restore steps, audit logs, and who can access customer data in this repo and its services.

AI actions

AI actions and tool-use guardrails

39

Do not launch until this area has guardrails.

AI and tool-call paths need allowlists, strict schemas, prompt boundaries, spend caps, and approval gates.

What to do in this repo

Find every LLM/tool-call path, add tool allowlists and schemas, isolate user-provided prompt data, set spend limits, and require human approval for irreversible actions.

Must fix before launchAccess

Privileged actions need explicit authorization boundaries

Block launch until this is fixed and re-scanned.

Suggested branch: hardening/auth-boundaries

Where Deploia saw it

Admin-like routes and database writes appear in the sample path, but the scan cannot confirm role or permission checks around those actions.

Why it matters

A normal user may be able to reach sensitive workflows if route-level checks are incomplete.

Next action

Add centralized authorization middleware, role checks around privileged actions, and tests that prove denied users stay denied.

Fix before real usersAI actions

AI tool execution needs guardrails before launch

Fix this before inviting customers or handling sensitive workflows.

Suggested branch: hardening/ai-tool-guardrails

Where Deploia saw it

The app uses LLM or provider integrations, but no budget cap, prompt-injection boundary, tool allowlist, or human approval gate is shown.

Why it matters

A malicious prompt or unexpected model output could trigger costly, unsafe, or data-exposing behavior.

Next action

Find every LLM/tool-call path, add schemas and allowlists, isolate user prompt data, cap spend, and require human approval for irreversible actions.

Fix before real usersAccess

Payment webhook reliability is not proven

Fix this before inviting customers or handling sensitive workflows.

Suggested branch: hardening/webhook-reliability

Where Deploia saw it

Stripe integration is detected, but idempotency, replay protection, durable event logging, and failure recovery are not confirmed.

Why it matters

Duplicate, missed, or replayed payment events can create account and billing inconsistencies for real customers.

Next action

Persist webhook events, verify signatures, enforce idempotency keys, and add retry-safe state transitions.

Before launch

Remove the risks that can expose users, money, data, or irreversible AI actions.

  • Harden auth and webhook paths
  • Add health endpoint and error tracking
  • Define AI tool-call guardrails

First paid users

Make operations recoverable and auditable once customers rely on the app.

  • Run a backup and restore drill
  • Create an audit event table
  • Route alerts to a named incident owner

Scale phase

Turn the launch report into an ongoing release-readiness workflow.

  • Schedule continuous readiness checks
  • Track accepted risks
  • Export compliance evidence