Review a product before launch — Full Prompt Suite

A guided prompt system to expose launch gaps in security, monitoring, costs, support, and recovery.

8 downloadable Markdown files

Discovery, master, implementation, review and handoff prompts

Business-context worksheet and internal-use license

Immediate ZIP download after confirmed payment

Support: account and delivery help through AEVUS Support

Refund terms: reviewed under the Terms of Service

Built for: evidence-based readiness · security and recovery · cost and monitoring · go/no-go ownership

Illustrative example

A fictional web app has working signup but no evidence for error alerts or recovery.

A useful result: A readiness matrix marking those areas unknown, with owners, proof steps, and a go/no-go checklist.

Review before use: Do not mark the app ready until owners provide runtime evidence for the launch blockers.

Secure checkout by Stripe. AEVUS does not receive your complete card number.

What to provide

Product scope, architecture, environments, release plan, test evidence, owners, and known risks.

What you will get

A launch-readiness matrix, blockers, owner-based follow-ups, rollback plan, and evidence checklist.

Example: Fictional example: A small web app has working signup but lacks error alerts and a tested recovery path.

Copy the full prompt

Customize the bracketed fields.

Use approved business information and have a person review the result before acting.

Review this product's launch readiness without claiming that unverified checks passed.
Product and intended audience: [details]
Architecture, integrations, and data classes: [verified facts]
Environments and release process: [details]
Test and runtime evidence: [links or summaries]
Known risks and support owner: [details]

Assess security and permissions, privacy and data handling, accessibility, performance, monitoring and alerts, cost limits, customer support, backups and recovery, rollback, and incident ownership. For each area, state the requirement, evidence provided, status as pass, partial, fail, or unknown, responsible owner, and next check. Distinguish an implemented control from a tested control and a proposed control. Give the five highest launch blockers, a safe release and rollback checklist, and exact evidence needed for a human go/no-go decision. Verify current provider behavior in official documentation. Do not change configuration, run destructive tests, certify compliance, or deploy.

Response requirements:
- Begin with a short summary of the goal, confirmed facts, assumptions, and missing information.
- Ask focused clarification questions before completing the work when a missing answer would materially change the result.
- Use clear headings, tables, checklists, or numbered steps where they make the output easier to use.
- Keep source facts separate from recommendations. Quote or cite supplied evidence when the task depends on source material.
- Mark unsupported details, decisions, owners, dates, costs, credentials, and commitments as [TO CONFIRM].
- Identify the three most important risks, failure conditions, or quality checks.
- End with a practical next-action checklist that names the responsible role and the evidence needed to confirm completion.
- Include a final self-review: check the answer against this prompt, list any unmet requirement, and correct it before responding.
- Do not claim that you accessed a system, verified an external fact, completed an action, or tested the result unless evidence in this conversation proves it.

Get help adapting this prompt ↗

Version 1.0 · Updated 2026-10-10 · Free starter template. Evaluate the output in your approved environment.