name

indie-saas-launch-audit

description

Audit indie hacker SaaS launch readiness from a public website, local project codebase, provided evidence, or founder checklist. Use when an agent needs to inspect launch clarity, conversion readiness, SEO metadata, social previews, trust signals, mobile UX, auth/signup paths, analytics, emails, payments, launch hygiene, founder-only checks, or create concise Markdown and polished standalone HTML audit reports.

Indie SaaS Launch Audit

Overview

Use this skill to audit whether an indie SaaS product is ready to launch. Inspect the public website and the local codebase when available, separate verified evidence from founder-only checks, then produce practical launch fixes and, when requested, a user-friendly HTML report.

Workflow

Identify the audit mode:
- Hybrid audit: user provides a URL and the agent is running inside or near the product codebase. Use this as the default when possible.
- Codebase audit: user provides a repo but no public URL. Inspect implementation and mark production-only checks as needing confirmation.
- Public website audit: user provides only a URL. Inspect public evidence and mark code/private items as needing confirmation.
- Evidence-based audit: user provides URL, repo, screenshots, social links, analytics notes, launch posts, or other proof.
- Checklist/report work: user asks to improve the audit system, prompt, checklist, rubric, or HTML report format.
Gather the minimum context:
- Website URL, repo root, product name, target user, main outcome, pricing model, and optional launch evidence.
- If a codebase is available, map the framework, routes/pages, metadata implementation, public assets, config files, environment examples, and launch-related integrations.
- If context is missing, infer only from observable website or code evidence and label it as an inference.
Apply the verification boundary:
- Mark website-observable and codebase-observable items as Pass, Partial, or Fail.
- Use file paths, line numbers, URLs, screenshots, command output, or provided proof as evidence.
- Treat code evidence as implementation evidence, not proof that production services work.
- Mark live delivery, third-party dashboards, social activity, outreach, directory submissions, Search Console, and post-launch follow-up as Needs founder confirmation unless verified from provided evidence.
- Do not penalize unavailable codebase or founder-only unknowns when scoring a public-only audit.
Audit the launch surface:
- Landing page clarity, audience, outcome, positioning, product proof.
- CTA visibility, signup/demo path, pricing clarity, objection handling.
- SEO basics, indexability signals, title, description, H1, canonical, sitemap, robots.
- Social preview, favicon, app icon, structured data where relevant.
- Mobile UX, readability, accessibility basics, speed/performance risks.
- Trust signals, privacy, terms, contact, refund/cancellation, security notes.
- Codebase hygiene: routes, metadata, env handling, hard-coded secrets, debug logs, test data, 404/error/loading/empty states, analytics events, feedback capture, auth, email, payment, and deployment config.
- Founder-only launch operations: social posts, directories, communities, outreach, live dashboards, live email delivery, Search Console, and follow-up.
Produce an action-oriented report:
- Lead with score, short summary, verdict, and top fixes.
- Include evidence for each finding and label the evidence source: website, codebase, provided evidence, or founder confirmation.
- Put website findings, codebase findings, and founder-only checks in separate sections when useful.
- Keep recommendations practical for an indie founder launching soon.

References

Read references/audit-playbook.md for the detailed audit process, finding format, and founder-only verification map.

Read references/scoring-rubric.md when assigning category scores or the overall launch readiness score.

Read references/html-report-guidelines.md when creating launch-audit-report.html or giving instructions for a visual HTML report.

Read references/original-indie-hacker-saas-launch-checklist.md when the user asks to preserve, compare against, expand, or rework the original checklist.

Indie SaaS Launch Audit

Overview

Workflow

Identify the audit mode:

Hybrid audit: user provides a URL and the agent is running inside or near the product codebase. Use this as the default when possible.
Codebase audit: user provides a repo but no public URL. Inspect implementation and mark production-only checks as needing confirmation.
Public website audit: user provides only a URL. Inspect public evidence and mark code/private items as needing confirmation.
Evidence-based audit: user provides URL, repo, screenshots, social links, analytics notes, launch posts, or other proof.
Checklist/report work: user asks to improve the audit system, prompt, checklist, rubric, or HTML report format.

Gather the minimum context:

Website URL, repo root, product name, target user, main outcome, pricing model, and optional launch evidence.
If a codebase is available, map the framework, routes/pages, metadata implementation, public assets, config files, environment examples, and launch-related integrations.
If context is missing, infer only from observable website or code evidence and label it as an inference.

Apply the verification boundary:

Mark website-observable and codebase-observable items as Pass, Partial, or Fail.
Use file paths, line numbers, URLs, screenshots, command output, or provided proof as evidence.
Treat code evidence as implementation evidence, not proof that production services work.
Mark live delivery, third-party dashboards, social activity, outreach, directory submissions, Search Console, and post-launch follow-up as Needs founder confirmation unless verified from provided evidence.
Do not penalize unavailable codebase or founder-only unknowns when scoring a public-only audit.

Audit the launch surface:

Landing page clarity, audience, outcome, positioning, product proof.
CTA visibility, signup/demo path, pricing clarity, objection handling.
SEO basics, indexability signals, title, description, H1, canonical, sitemap, robots.
Social preview, favicon, app icon, structured data where relevant.
Mobile UX, readability, accessibility basics, speed/performance risks.
Trust signals, privacy, terms, contact, refund/cancellation, security notes.
Codebase hygiene: routes, metadata, env handling, hard-coded secrets, debug logs, test data, 404/error/loading/empty states, analytics events, feedback capture, auth, email, payment, and deployment config.
Founder-only launch operations: social posts, directories, communities, outreach, live dashboards, live email delivery, Search Console, and follow-up.

Produce an action-oriented report:

Lead with score, short summary, verdict, and top fixes.
Include evidence for each finding and label the evidence source: website, codebase, provided evidence, or founder confirmation.
Put website findings, codebase findings, and founder-only checks in separate sections when useful.
Keep recommendations practical for an indie founder launching soon.

References

Read references/audit-playbook.md for the detailed audit process, finding format, and founder-only verification map.

Read references/scoring-rubric.md when assigning category scores or the overall launch readiness score.

Read references/html-report-guidelines.md when creating launch-audit-report.html or giving instructions for a visual HTML report.

Read references/original-indie-hacker-saas-launch-checklist.md when the user asks to preserve, compare against, expand, or rework the original checklist.