indie-saas-shipper

$npx mdskill add elophanto/EloPhanto/indie-saas-shipper

Validate payment intent before writing a single line of code.

  • Identifies micro SaaS ideas with proven willingness to pay.
  • Integrates Stripe and LemonSqueezy for direct payment processing.
  • Enforces kill criteria based on 14-day first-dollar targets.
  • Delivers a prioritized roadmap focusing on distribution-first execution.

SKILL.md

.github/skills/indie-saas-shipperView on GitHub ↗
---
name: indie-saas-shipper
description: Use when shipping a small, paid SaaS micro-tool from idea → live → first dollar. Goes against "build it and they'll come" — every step has a kill criterion, a 14-day-to-first-dollar default budget, and forces distribution before code. Geography-neutral (Stripe/LemonSqueezy), no platform middlemen.
---

## Triggers

- ship a saas
- ship a micro saas
- launch indie product
- build a paid tool
- micro tool with stripe
- monetize this idea
- bootstrap a saas
- launch on product hunt
- launch on indie hackers
- $9/mo product
- can we sell this

# Indie SaaS Shipper

## Overview

Most indie SaaS attempts fail not because the code is bad but because **the
distribution doesn't exist** and **the buyer was never validated**. This skill
exists to invert the default order: validate willingness-to-pay before
writing code, ship a paid landing page before a product, and kill the idea
fast if the signal isn't there.

**Iron rules:**
1. **No code before someone says "I'd pay."** A tweet, a DM, or a Stripe
   pre-order — but a real human signal, not a poll.
2. **First dollar in 14 days or kill it.** Not first sign-up. First *paid*
   transaction. The clock starts when phase 2 begins.
3. **One product at a time.** Five half-shipped products earn $0; one
   shipped product earns something. Sequential, not parallel.
4. **No "free tier" until paid traction exists.** Free tier is a customer
   acquisition tactic, not a starting point.

## Phase 1 — idea triage (≤30 minutes)

Before anything else, score the idea on three axes (1–5):

- **Pain intensity:** is this a vitamin or a painkiller? Painkillers convert.
- **Buyer reachability:** can you reach 100 buyers from your existing
  network/audience in a week? If no → kill or come back when you can.
- **Build-to-revenue ratio:** can a working v1 ship in ≤7 days of agent
  build time? If no → scope it down or kill.

Score below 9/15: kill. Score 9–11: maybe, surface caveats. Score 12+:
proceed.

Bias toward **dev tools, AI-augmented workflow tools, and niche B2B utilities**
where buyers already pay for similar things and are easy to find. Avoid
consumer apps (CAC eats you), ad-supported tools (scale game), and
"productivity for everyone" framings (no buyer profile).

## Phase 2 — willingness-to-pay validation (3–5 days, no code)

Before opening an editor:

1. **Write the landing page first.** One paragraph: who it's for, what it
   does, what it costs. Three pricing tiers ($9 / $19 / $49 monthly is the
   reference shape — adjust to value).
2. **Set up Stripe payment links** (Stripe in 100+ countries; LemonSqueezy
   if VAT/MoR is a concern). No app, no auth, just a page and a "Buy" button
   that 404s after payment with a "thanks, you'll get access in 48h" page.
3. **Show it to 20 people in the buyer profile.** DMs, X replies, niche
   subreddits where soliciting is allowed. Track responses verbatim.
4. **Acceptance criterion:** ≥3 sign-ups OR ≥1 paid pre-order in 5 days.
   Below that, the idea isn't validated. Kill or pivot.

Refunds are fine. The signal is that someone clicked "buy."

## Phase 3 — minimum shippable product (5–7 days)

Stack defaults — pick these unless there's a specific reason not to:

- Frontend: Next.js + Tailwind + shadcn/ui (App Router)
- Backend: Next.js API routes (or FastAPI if Python-heavy)
- DB: Postgres on Neon / Supabase (free tier fine)
- Auth: Clerk or Supabase Auth
- Payments: **Stripe** (default) or LemonSqueezy (if VAT MoR matters)
- Hosting: Vercel (frontend) + Railway/Fly (workers)
- Analytics: Plausible (privacy-friendly, owners don't fight cookie banners)

Build only what the landing page promised. **No nice-to-haves until first
paying user.** Onboarding email, dashboards, settings pages — all later.

The agent's job here is to ship code; the user's job is to look at the
landing page output before it goes live and reject anything that
overpromises.

## Phase 4 — distribution (continuous, starting day 1)

Distribution is a parallel track to build, not a sequential phase. Start day 1.

- **Where to launch:** Product Hunt (Tuesday/Wednesday, 12:01 AM PST), Indie
  Hackers (Show IH section), Hacker News (Show HN — only if there's a real
  technical angle), the niche subreddits in scope, and X.
- **Don't launch on all of them on the same day.** Sequence: niche channels
  → IH → PH → HN. The flop on one platform poisons the next.
- **The agent owns content; the user owns voice.** The agent drafts the
  launch posts, threads, replies, screenshots. The user posts under their
  identity. Bot launches feel bot-launched.

## Phase 5 — kill or scale (day 14 review)

Hard gate at day 14 from phase 2 start:

- 0 paying customers → **kill.** Move to next idea. Park the code in a
  `graveyard/` folder; record what was learned in `learned/saas/{name}.md`.
- 1–2 paying customers → **investigate the moat.** Were they friends? Did
  they discover it organically? Most "first 2 customers were friends" outcomes
  don't compound. Continue only if non-network customers exist.
- 3+ paying customers from cold traffic → **scale.** Reinvest revenue into
  ads, more landing pages, a referral mechanic. This is now a real product.

## Templates

### Validation DM template

> Hey [name], saw your [post/tweet/repo] on [topic]. Building a small tool
> that [one-sentence problem statement] — landing page here: [link]. Would
> $[price]/mo solve a real pain for you, or am I way off?

### Refund-friendly preorder copy

> Pay $X today, full access in 48 hours. If we don't ship in 7 days you get
> a full refund, no questions. We don't keep the money until you have a
> working product in your hands.

### Kill-it-and-document template (`learned/saas/{name}.md`)

> ## Killed: {name} — {date}
> - Pitch: {one line}
> - Validation outcome: {n signups / m paid in y days}
> - Why it died: {real reason, not "no time"}
> - What I'd reuse: {tech, audience, distribution channel}
> - What I won't repeat: {assumption that broke}

## Failure modes / when to refuse

- "Let's build it and figure out monetization later" → refuse. No.
- "It's free for the first 1000 users" → refuse. That's not a SaaS, that's
  a hobby with hosting costs.
- "Build the entire admin dashboard / settings / SSO before launch" → refuse.
  Ship the one feature the landing page promised.
- "I want to launch on Friday" → push back. PH/IH launch days matter.

## Verify

- The deliverable for this phase exists as a concrete artifact (doc, ticket, board, repo) and its location is shared, not described
- Each commitment has an owner name, a due date, and a definition-of-done that someone other than the author could check
- Risks are listed with likelihood/impact and a named mitigation, not as a generic 'risks: TBD' bullet
- Dependencies on other teams/vendors/agents are explicit; an ack from each dependency is recorded or marked 'pending'
- Success criteria for the next phase are numeric or otherwise objectively testable
- A rollback / kill-switch / 'we will stop if X' criterion is written down before work starts

## Anti-patterns to flag

- **The polish trap:** rewriting the landing page for the 4th time instead
  of DMing buyer #21.
- **The infinite scope creep:** "v1 also needs Slack integration." It does
  not. v1 needs one paying customer.
- **The free-tier escape hatch:** when validation fails, the temptation is
  "let's just make it free and grow." That's a different business; restart
  phase 1 if you go there.

More from elophanto/EloPhanto

SkillDescription
12-principles-of-animationAudit animation code against Disney's 12 principles adapted for web. Use when reviewing motion, implementing animations, or checking animation quality. Outputs file:line findings.
accessibility-auditingAudit interfaces against WCAG 2.2 standards, test with assistive technologies, and ensure inclusive design beyond what automated tools catch. Adapted from msitarzewski/agency-agents.
agency-phase-0-discoveryIntelligence and discovery phase — validate opportunity before committing resources. Adapted from msitarzewski/agency-agents.
agency-phase-1-strategyStrategy and architecture phase — define what to build, how to structure it, and what success looks like. Adapted from msitarzewski/agency-agents.
agency-phase-2-foundationFoundation and scaffolding phase — build technical and operational foundation before feature development. Adapted from msitarzewski/agency-agents.
agency-phase-3-buildBuild and iterate phase — implement all features through continuous Dev-QA loops with orchestrated multi-agent sprints. Adapted from msitarzewski/agency-agents.
agency-phase-4-hardeningQuality and hardening phase — the final quality gauntlet proving production readiness with evidence. Adapted from msitarzewski/agency-agents.
agency-phase-5-launchLaunch and growth phase — coordinate go-to-market execution across all channels for maximum impact. Adapted from msitarzewski/agency-agents.
agency-phase-6-operateOperate and evolve phase — sustained operations with continuous improvement for live products. Adapted from msitarzewski/agency-agents.
agency-strategyNEXUS multi-agent orchestration strategy — the complete operational playbook for coordinating specialized AI agents across project phases. Adapted from msitarzewski/agency-agents.