# Indie Saas Launch Audit

> 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.

- Skill: `deepakness/indie-saas-launch-audit` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add deepakness/indie-saas-launch-audit`
- Raw SKILL.md: https://api.skillmd.com/api/skills/deepakness/indie-saas-launch-audit/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Marketing & Growth
- Author: deepakness (https://skillmd.com/u/deepakness)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/deepakness/indie-saas-launch-audit

---


# 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

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.