ShipKitDemo
Enter the demo

You're looking at the live demo of ShipKit — a real deployment with seeded data.Get the template at shipkit.sh

This is a live demo of ShipKit.

A real deployment on seeded data — dashboard, billing, credits and a read-only admin console. One click gives you a throwaway account that is erased within a day; the template itself is at shipkit.sh.

Enter the demoRead the docs

Built on

  • TanStack Start
  • React
  • TypeScript
  • Tailwind CSS
  • shadcn/ui
  • Vite
  • Bun
  • Cloudflare
  • Node.js
  • Drizzle
  • better-auth
  • Stripe
  • Creem
  • Resend

With your agent

Say what you want. It does the rest.

  • Claude Code
  • Codex
  • Cursor
  • GitHub Copilot
  • Windsurf
  • opencode
  • Zed
  • Amp

  1. Step 1

    Running in one command

    /setup
    bun install
    bun run db:migrate:local
    bun run dev
    http://localhost:3000/

  2. Step 2

    Payments wired by the agent

    /stripe
    stripe prices create …
    Wrote ids to plans.ts
    stripe listen
    checkout → 200

  3. Step 3

    Rules it cannot quietly break

    Add invoices
    /add-feature invoices
    ✗ no permission check
    Added requirePermission
    ✓ all tests pass

This is the whole app.

  • The app

    A guarded shell: home, account settings, plan and credits.

  • Billing

    Checkout, prorated upgrades, downgrades at period end, receipts.

  • Admin console

    Revenue and growth at a glance, then users, orders, roles, audit and email logs.

  • Marketing site

    Prerendered landing, pricing, docs, blog and legal — in two languages.

The signed-in home page: sidebar, current plan, credit balance and a getting-started checklist.
The plan and billing page: the active Pro plan with its renewal date, and the payment history below.
The admin console overview: revenue, subscriptions, users and sign-ups, a revenue chart, and what needs attention.
The public marketing site: header, headline, calls to action and the technology stack.

In the box

The parts you would have written anyway.

  1. 01

    Payments, provider-neutral

    src/features/billing
    • Stripe
    • Creem
    • One internal event type
    • Upgrade now, downgrade at period end
    • A refund undoes an upgrade
    • Switch with one env var
  2. 02

    Passwordless auth

    src/features/auth
    • Google
    • GitHub
    • Emailed sign-in code
    • No passwords, no reset flow
    • Sessions in D1
  3. 03

    Metered credits

    src/features/credits
    • Monthly grant per plan
    • Packs that never expire
    • Spend without a transaction
    • Full ledger
  4. 04

    An admin console

    src/routes/_app/admin
    • KPIs and trends
    • Users, subscriptions, orders
    • Roles and permissions
    • Audit and email logs
    • Admin JSON API
  5. 05

    Content and i18n

    src/features/content
    • MDX content
    • Blog and docs
    • Compiled at build time
    • EN / 中文
    • Locale in the URL
  6. 06

    The boring half

    .github/workflows/ci.yml
    • Typecheck and lint
    • Unit tests
    • Playwright e2e
    • Deploy refuses pending migrations
    • Deletion recipes verified in CI
  7. 07

    And the rest

    src/features
    • R2 file storage
    • Transactional email
    • In-app notifications
    • In-app feedback
    • Waitlist gate
    • Affiliate programme
    • Analytics
    • API keys

Pricing

The plans are already in the repo.

See pricing

  • Free

    $0/mo

    0 credits / month
    ≈ 0 actions a month

  • Starter

    $0/mo

    0 credits / month
    ≈ 0 actions a month

  • Pro

    $0/mo

    0 credits / month
    ≈ 0 actions a month

  • Studio

    $0/mo

    0 credits / month
    ≈ 0 actions a month

Questions

Things people ask before they clone it.

Stripe or Creem?

Either, and both at once. The webhook routes only verify, deduplicate and translate a payload into one internal event; features never import a provider client. PAYMENT_PROVIDER picks who takes new checkouts, and existing subscriptions keep renewing wherever they started.

Why Cloudflare Workers and not a Node host?

Because D1 and R2 are bindings, not services with credentials: no connection string, no pool, no S3 keys, and local dev runs the same runtime as production. The trade is that workerd forbids some Node patterns — the template already works around the ones that matter, like runtime-eval MDX.

What does "every feature is deletable" actually mean?

Each optional feature is a directory plus a handful of one-line registrations — a schema barrel line, a handler import, a nav row. The /delete-feature skill knows the recipe for each, and a CI job runs every recipe on every pull request and fails if one has rotted.

What does it cost to run?

On a small app, close to nothing: Workers, D1 and R2 all have free tiers that cover early traffic, and the only always-on cost is your domain. Email and payments bill per use.

Sign in and look around.

Enter the demoRead the docs