← All Posts
Essay

I Built a Plugin That Makes Claude Code Actually Launch-Ready — Here's What It Catches

How I designed, tested, and shipped Shipwise — a Claude Code plugin with 15 domain skills, 4 lifecycle hooks, and 45+ copy-paste templates that covers the full webapp launch lifecycle.

AI ToolingClaude Code
Mar 2026 · 6 min read

I ran the same auth prompt in Claude Code twice — once with my plugin active, once without. Without: 18/40 on a security rubric. With: 36/40. Twenty-four specific security improvements that Claude doesn't suggest on its own. That's what convinced me Shipwise was worth shipping.

The Problem

Claude Code writes great code for what you ask for. It writes nothing for what you forget to ask for. No rate limiting on your auth endpoints. No CSRF protection. No health endpoint for your load balancer. No privacy policy. Every launch, the same rediscovery — and always at the worst possible time.

What /shipwise Actually Looks Like

One command kicks it off:

promptops
> /shipwise Running diagnostic interview... ✓ Stack detected: Next.js + Postgres + Vercel ✓ Auth: Clerk (managed provider — adjusting security checklist) ✓ Billing: Stripe integration found ✓ 23 checklist items generated ✓ 4 hooks installed [Shipwise] Ready: 42% | P0 gaps: 5 Top priority: Set up error tracking (Sentry — 15 min)

One command. It scanned my codebase, detected Clerk for auth, Stripe for billing, found my Prisma schema with 12 models, counted my test files — and told me the 5 things that would bite me on launch day.

You can see the full experience at harmansidhudev.github.io/shipwise.

The Before/After That Proved It Works

Same prompt. Same project. Same model. The only difference is whether Shipwise is active.

Without Shipwise (18/40):

// What Claude generates for "set up user auth with proper security"
- Basic bcrypt hashing (no cost factor specified)
- No rate limiting on login endpoint
- No CSRF protection
- Plain session cookies (no httpOnly, no sameSite)
- No account lockout after failed attempts
- No MFA consideration
- Generic error: "Invalid credentials" (but leaks user existence)
- No password strength validation

With Shipwise (36/40):

// Same prompt, same project — Shipwise active
- Argon2id with explicit memory/time/parallelism params
- Rate limiting: 5 failed attempts → 15-minute lockout
- CSRF tokens on all state-changing routes
- httpOnly + sameSite=strict + secure cookies
- Progressive account lockout (1min → 5min → 15min → 1hr)
- MFA implementation guidance with TOTP setup
- Structured error: { code: "AUTH_FAILED" } — no user enumeration
- Password checked against HaveIBeenPwned API

Twenty-four differences. Every one of them matters in production.

The Smart Part — It Knows YOUR Stack

If your project uses Clerk or Auth0, Shipwise doesn't waste your time with bcrypt guidance — your auth provider already handles password hashing, breach checking, and account lockout. Instead, it focuses on what you're STILL responsible for:

promptops
[Shipwise] Managed auth detected: Clerk Skipping: password hashing, breach checking, account lockout (provider-managed) Focusing on YOUR responsibilities: → Rate limiting at the application layer (Clerk protects their endpoints, not yours) → CSRF protection for non-API routes → Session cookie configuration via Clerk SDK → Security headers (CSP, HSTS, X-Frame-Options) → MFA enablement via Clerk dashboard

This is the difference between a generic checklist and one that understands your project. Full details on how detection works at harmansidhudev.github.io/shipwise.

What It Actually Covers — 4 Phases, Real Examples

Design

Before you write a line of code, Shipwise surfaces the JTBD framework for validating your idea, a Lean Canvas template you can fill in immediately, and a 50-item WCAG 2.2 AA accessibility checklist. Starting a company? There's an entity formation decision tree (LLC vs C-Corp vs S-Corp) and a co-founder agreement outline.

/design-validate → JTBD interview, Lean Canvas, competitive positioning
/design-a11y → WCAG 2.2 AA checklist with copy-paste ARIA patterns

Build

Choosing your stack? Shipwise compares 5 open-source SaaS boilerplates (Open SaaS, ixartz, BoxyHQ, apptension, paralect/ship) and maps which checklist items each one already satisfies — so you know what's done before you start. Building for B2B? There's a multi-tenancy patterns guide with copy-paste Postgres RLS policies.

/build-stack → Boilerplate comparison matrix + stack recommendation
/build-db → Multi-tenancy patterns: shared DB, Postgres RLS, schema-per-tenant

Ship

The launch day timeline is minute-by-minute:

T-2h  Deploy to staging, full regression
T-1h  Run security scan, check error tracking
T-30m Warm caches, verify DNS
T-0   Go live
T+15m Check error rates, monitor latency
T+30m Email the waitlist

Plus rollback plan templates, war room setup guides, and a staging regression checklist.

Grow

Post-launch: event naming conventions (noun_verb format), funnel tracking from signup to first payment, retention cohort analysis templates (D1, D7, D30), and email drip sequences — onboarding on day 0/1/3/7, re-engagement at day 14, churn prevention on cancel intent.

/grow-analytics → Event taxonomy + funnel definitions
/grow-email → 7-email onboarding sequence, copy-paste ready

Real Scenarios From Testing

I built a 12-scenario QA suite with 3 developer archetypes. Here are the ones that surprised me most:

The solo founder who needed a tech stack. A beginner prompt: "I need to pick my tech stack. I know a little React. Need a database and hosting." Without Shipwise, Claude gives the usual "it depends on your use case" answer. With Shipwise, the architecture skill triggers and gives a clear recommendation: Next.js because she already knows React, Postgres because it's the safest default, Vercel because zero-config deploys. Beginner-friendly language. No jargon.

The senior engineer's tRPC vs GraphQL tradeoff. A senior prompt: "Deciding between tRPC and GraphQL for a monorepo with real-time subscriptions." Shipwise surfaces the real tension: tRPC is ideal for monorepos (same team, end-to-end types), but GraphQL has stronger subscription support. The recommendation: start with tRPC for 90% of your API, add a thin GraphQL layer for the subscription features. Nuanced, not hand-wavy.

The pre-launch audit. Running /launch-audit on a 50-file SaaS project:

promptops
[Shipwise] Codebase Audit Results: ✓ Detected: Prisma, Clerk, Stripe, Vercel, ESLint, Prettier, Vitest, 2 test files ✗ Missing: CI/CD pipeline, error tracking, health endpoint, privacy policy, security headers ...15 more gaps Readiness: 32% | Top 3 priorities: 1. Error tracking (Sentry — 15 min) 2. Health endpoint for Vercel checks (5 min) 3. Security headers middleware (10 min)

Not generic advice — an audit of YOUR actual project. The auditor detected 9/9 tech components in the test fixture.

Try It

Shipwise is open source, MIT licensed, and takes one command to install.

/plugin install shipwise
/shipwise

See the full experience, test scenarios, and documentation:

  • Landing page — the complete overview with scenario carousel showing all 12 test results
  • GitHub — 15 skills, 45+ reference docs, full source
  • Test results — 12 scenarios, 3 fixtures, every finding documented

Ship wisely.


Harman Sidhu is a Product + Platform Engineer building reliable AI tooling. More at harmansidhudev.com.

Get notified when I publish next.

One email per post, no spam. Unsubscribe anytime.

Get in Touch

What brings you here?

Professional Inquiry

Looking to hire, collaborate on platform engineering, or discuss how I approach migrations and infrastructure? I'd love to hear from you.

LinkedIn