Publish complete, deployable applications built with Claude Code. From boilerplates to production-ready tools — your app becomes an installable product that buyers launch in minutes.

TutorialBeginner

Publish complete, deployable applications built with Claude Code. From boilerplates to production-ready tools — your app becomes an installable product that buyers launch in minutes.

Applications are the highest-complexity and often highest-price products on MyClaude. They represent a complete solution to a complete problem. A buyer doesn't get a component or a thinking framework — they get a working thing, ready to configure and deploy. The time they save isn't measured in minutes. It's measured in weeks.

If you've built something with Claude Code that solves a real problem — a SaaS boilerplate, an internal tool, a specialized dashboard, a content management system — you can package it and sell it. The person who buys it gets your months of decisions, your architecture choices, your hard-won understanding of what actually works.

What is an Application?

An Application is a complete codebase installed into ./myclaude-products/. It includes source code, configuration files, documentation, and setup scripts. When a buyer installs it, they get a working starting point that's ready to configure and deploy.

Concept	What it means for you
Source code	The complete application — not a template with placeholders
README.md	The single most important file — first thing buyers read
Setup scripts	Automate environment setup, dependency install, database init
`vault.yaml`	The manifest — name, price, version, metadata
`./myclaude-products/`	Where it installs on the buyer's machine
Demo screenshots	Visual proof of what they're getting before they buy

The difference between an Application and a code snippet: a snippet solves one function. An Application solves a whole workflow, deployed and running.

Who creates Applications?

You need to have built something that works. That's it.

Developers — sell the boilerplate you wish existed when you started your last project
Agency owners — package internal starter kits as external products
Indie hackers — turn a completed side project into a sellable template
Consultants — offer a configured starting point for every client engagement
Educators — create teaching applications with progressive complexity
Domain specialists — build tools for your industry that generalist developers don't know to build

If you built it once and would build it again for someone else — package it. Let MyClaude be the distribution.

Create your first Application

Let's package a SaaS dashboard boilerplate. Concrete, complete, immediately deployable.

Scaffold the project

$ myclaude init saas-dashboard-starter --type applications
$ cd saas-dashboard-starter

The scaffold creates the directory structure and a starter vault.yaml. Your actual application code goes in the same directory.

Structure your application

Clean structure signals quality. Buyers judge before they buy:

saas-dashboard-starter/
├── README.md                  # The most important file — write it first
├── vault.yaml                 # MyClaude manifest
├── package.json
├── .env.example               # All required env vars, documented
├── setup.sh                   # One-command setup script
├── docs/
│   ├── architecture.md        # How the system is designed
│   ├── deployment.md          # How to deploy to Vercel, Railway, etc.
│   └── customization.md       # How to make it yours
├── src/
│   ├── app/                   # Application code
│   ├── components/
│   ├── lib/
│   └── types/
├── scripts/
│   ├── setup.sh               # Environment setup
│   └── seed.sh                # Demo data (optional but valuable)
└── screenshots/
    ├── dashboard.png
    ├── analytics.png
    └── settings.png

Write README.md (write this first)

The README is your product page in miniature. Buyers read it before purchasing. Developers read it before using. It is the most important file in your package.

# SaaS Dashboard Starter

A complete Next.js SaaS boilerplate with authentication, billing, analytics,
and team management. Built with Claude Code. Tested in production.

## What's included

- **Authentication** — Email/password, Google OAuth, magic links (NextAuth.js)
- **Billing** — Stripe subscriptions with webhook handling, customer portal
- **Team management** — Invite flow, roles (owner/admin/member), permissions
- **Analytics dashboard** — Usage metrics, MRR, churn, active users
- **Settings** — Profile, notifications, billing, team, API keys
- **Email system** — Transactional emails via Resend (templates included)
- **Admin panel** — User management, plan overrides, feature flags

## Requirements

- Node.js 18+
- PostgreSQL (or Supabase — setup guide included)
- Stripe account
- Resend account (or swap for any email provider)

## Quick start (5 minutes)

```bash
git clone [your-repo-url]
cd saas-dashboard-starter
cp .env.example .env.local
./setup.sh
npm run dev

Deploy to production

See docs/deployment.md for Vercel, Railway, and self-hosted options. One-click deploy button available.

What you're skipping

Authentication: ~3 days. Billing integration: ~5 days. Team management: ~4 days. Email system: ~2 days. Admin panel: ~3 days. That's 17 days of work already done.


### Write .env.example (never .env)

Every secret, documented. Every secret, placeholder. Never ship real values.

```bash
# .env.example

# Database
DATABASE_URL=postgresql://user:password@localhost:5432/saas_db

# Authentication
NEXTAUTH_SECRET=generate-with-openssl-rand-base64-32
NEXTAUTH_URL=http://localhost:3000
GOOGLE_CLIENT_ID=your-google-oauth-client-id
GOOGLE_CLIENT_SECRET=your-google-oauth-client-secret

# Stripe
STRIPE_SECRET_KEY=sk_test_your-stripe-secret-key
STRIPE_WEBHOOK_SECRET=whsec_your-webhook-secret
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_test_your-publishable-key

# Email
RESEND_API_KEY=re_your-resend-api-key
EMAIL_FROM=noreply@yourdomain.com

# App
NEXT_PUBLIC_APP_URL=http://localhost:3000

Write a setup script

The best Application products make setup feel effortless:

#!/bin/bash
# setup.sh

echo "Setting up SaaS Dashboard Starter..."

# Install dependencies
npm install

# Check for required env vars
if [ ! -f .env.local ]; then
  echo "Creating .env.local from template..."
  cp .env.example .env.local
  echo "Fill in .env.local before running npm run dev"
fi

# Run database migrations
echo "Running database migrations..."
npm run db:migrate

echo "Setup complete. Run: npm run dev"

Wire vault.yaml

name: saas-dashboard-starter
version: 1.0.0
type: applications
title: "SaaS Dashboard Starter — Auth, Billing, Teams in One Install"
description: "A production-ready Next.js SaaS boilerplate. Authentication, Stripe billing, team management, analytics dashboard, admin panel — skip 3 weeks of setup and start building your product."
price: 149.99
tags:
  - nextjs
  - saas
  - boilerplate
  - stripe
  - authentication
  - typescript

Test locally (the full buyer experience)

Run through the complete install as if you were a buyer:

$ myclaude validate
$ # Simulate: install to a fresh directory
$ mkdir -p /tmp/test-install/myclaude-products
$ cp -r . /tmp/test-install/myclaude-products/saas-dashboard-starter
$ cd /tmp/test-install/myclaude-products/saas-dashboard-starter
$ ./setup.sh
$ npm run dev

Does it work? Can you get to a running app in under 10 minutes from a fresh directory? If not, find where it breaks and fix it. The standard is: a developer who has never seen your code should be able to get it running in one sitting.

Publish

$ myclaude validate
$ myclaude publish

Your Application is now live on MyClaude.

What makes a great Application

The difference between an application that sells and one that gets refund requests:

Mediocre	Great
Works on the creator's machine only	Works from a clean install on any machine
Hardcoded values everywhere	Everything configurable via environment variables
README written as afterthought	README written first, before any code
No .env.example	Every required variable documented with examples
Manual setup, 20 steps	One setup script, under 5 minutes
No screenshots	Visual preview of every major screen
Outdated dependencies	Dependencies maintained and up to date
No documentation	Architecture, deployment, and customization guides

The real product is the experience of getting it working. Code can be mediocre but if the setup is smooth and the README is honest, buyers are satisfied. Conversely, excellent code buried under a confusing setup creates poor reviews. Optimize for time-to-working.

Advanced: Demo data and seeding

Applications that include realistic demo data convert better and get better reviews. Add a seed script:

# scripts/seed.sh
npm run db:seed:demo
# Creates: 3 demo users, 2 plans, sample analytics data, example teams

Document it in your README. Buyers can explore the full application experience before they start building.

Common questions

What tech stacks work best for Applications?

The most popular stacks on MyClaude are Next.js, Remix, and Astro for web applications. For CLI tools: Node.js with TypeScript. For APIs: Express, Fastify, or Hono. Use what you know best — a confident implementation in any stack beats an uncertain one in the "right" stack.

Can I sell an application that uses paid third-party services?

Yes, as long as you're clear in your description about required external services and their costs. List them in your README. Buyers who understand the full cost picture leave better reviews and fewer complaints.

Should I include my own API keys for demos?

Never. Use .env.example with placeholder values and clear instructions. Including real API keys is a security risk for you and a liability for buyers.

How do I handle updates?

Version semantically. Increment version in vault.yaml for each release. Document breaking changes prominently. Buyers who purchased your application expect updates to be compatible — if you're making breaking changes, give advance notice and a migration guide.

vault.yaml Reference — every field explained
Publishing Guide — the full publishing process
Monetization — pricing applications appropriately
Product Categories — understand how Applications differ from Systems

TutorialBeginner

Publish complete, deployable applications built with Claude Code. From boilerplates to production-ready tools — your app becomes an installable product that buyers launch in minutes.

What is an Application?

Concept	What it means for you
Source code	The complete application — not a template with placeholders
README.md	The single most important file — first thing buyers read
Setup scripts	Automate environment setup, dependency install, database init
`vault.yaml`	The manifest — name, price, version, metadata
`./myclaude-products/`	Where it installs on the buyer's machine
Demo screenshots	Visual proof of what they're getting before they buy

The difference between an Application and a code snippet: a snippet solves one function. An Application solves a whole workflow, deployed and running.

Who creates Applications?

You need to have built something that works. That's it.

Developers — sell the boilerplate you wish existed when you started your last project
Agency owners — package internal starter kits as external products
Indie hackers — turn a completed side project into a sellable template
Consultants — offer a configured starting point for every client engagement
Educators — create teaching applications with progressive complexity
Domain specialists — build tools for your industry that generalist developers don't know to build

If you built it once and would build it again for someone else — package it. Let MyClaude be the distribution.

Create your first Application

Let's package a SaaS dashboard boilerplate. Concrete, complete, immediately deployable.

Scaffold the project

$ myclaude init saas-dashboard-starter --type applications
$ cd saas-dashboard-starter

The scaffold creates the directory structure and a starter vault.yaml. Your actual application code goes in the same directory.

Structure your application

Clean structure signals quality. Buyers judge before they buy:

saas-dashboard-starter/
├── README.md                  # The most important file — write it first
├── vault.yaml                 # MyClaude manifest
├── package.json
├── .env.example               # All required env vars, documented
├── setup.sh                   # One-command setup script
├── docs/
│   ├── architecture.md        # How the system is designed
│   ├── deployment.md          # How to deploy to Vercel, Railway, etc.
│   └── customization.md       # How to make it yours
├── src/
│   ├── app/                   # Application code
│   ├── components/
│   ├── lib/
│   └── types/
├── scripts/
│   ├── setup.sh               # Environment setup
│   └── seed.sh                # Demo data (optional but valuable)
└── screenshots/
    ├── dashboard.png
    ├── analytics.png
    └── settings.png

Write README.md (write this first)

The README is your product page in miniature. Buyers read it before purchasing. Developers read it before using. It is the most important file in your package.

# SaaS Dashboard Starter

A complete Next.js SaaS boilerplate with authentication, billing, analytics,
and team management. Built with Claude Code. Tested in production.

## What's included

- **Authentication** — Email/password, Google OAuth, magic links (NextAuth.js)
- **Billing** — Stripe subscriptions with webhook handling, customer portal
- **Team management** — Invite flow, roles (owner/admin/member), permissions
- **Analytics dashboard** — Usage metrics, MRR, churn, active users
- **Settings** — Profile, notifications, billing, team, API keys
- **Email system** — Transactional emails via Resend (templates included)
- **Admin panel** — User management, plan overrides, feature flags

## Requirements

- Node.js 18+
- PostgreSQL (or Supabase — setup guide included)
- Stripe account
- Resend account (or swap for any email provider)

## Quick start (5 minutes)

```bash
git clone [your-repo-url]
cd saas-dashboard-starter
cp .env.example .env.local
./setup.sh
npm run dev

Deploy to production

See docs/deployment.md for Vercel, Railway, and self-hosted options. One-click deploy button available.

What you're skipping

Authentication: ~3 days. Billing integration: ~5 days. Team management: ~4 days. Email system: ~2 days. Admin panel: ~3 days. That's 17 days of work already done.


### Write .env.example (never .env)

Every secret, documented. Every secret, placeholder. Never ship real values.

```bash
# .env.example

# Database
DATABASE_URL=postgresql://user:password@localhost:5432/saas_db

# Authentication
NEXTAUTH_SECRET=generate-with-openssl-rand-base64-32
NEXTAUTH_URL=http://localhost:3000
GOOGLE_CLIENT_ID=your-google-oauth-client-id
GOOGLE_CLIENT_SECRET=your-google-oauth-client-secret

# Stripe
STRIPE_SECRET_KEY=sk_test_your-stripe-secret-key
STRIPE_WEBHOOK_SECRET=whsec_your-webhook-secret
NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY=pk_test_your-publishable-key

# Email
RESEND_API_KEY=re_your-resend-api-key
EMAIL_FROM=noreply@yourdomain.com

# App
NEXT_PUBLIC_APP_URL=http://localhost:3000

Write a setup script

The best Application products make setup feel effortless:

#!/bin/bash
# setup.sh

echo "Setting up SaaS Dashboard Starter..."

# Install dependencies
npm install

# Check for required env vars
if [ ! -f .env.local ]; then
  echo "Creating .env.local from template..."
  cp .env.example .env.local
  echo "Fill in .env.local before running npm run dev"
fi

# Run database migrations
echo "Running database migrations..."
npm run db:migrate

echo "Setup complete. Run: npm run dev"

Wire vault.yaml

name: saas-dashboard-starter
version: 1.0.0
type: applications
title: "SaaS Dashboard Starter — Auth, Billing, Teams in One Install"
description: "A production-ready Next.js SaaS boilerplate. Authentication, Stripe billing, team management, analytics dashboard, admin panel — skip 3 weeks of setup and start building your product."
price: 149.99
tags:
  - nextjs
  - saas
  - boilerplate
  - stripe
  - authentication
  - typescript

Test locally (the full buyer experience)

Run through the complete install as if you were a buyer:

$ myclaude validate
$ # Simulate: install to a fresh directory
$ mkdir -p /tmp/test-install/myclaude-products
$ cp -r . /tmp/test-install/myclaude-products/saas-dashboard-starter
$ cd /tmp/test-install/myclaude-products/saas-dashboard-starter
$ ./setup.sh
$ npm run dev

Publish

$ myclaude validate
$ myclaude publish

Your Application is now live on MyClaude.

What makes a great Application

The difference between an application that sells and one that gets refund requests:

Mediocre	Great
Works on the creator's machine only	Works from a clean install on any machine
Hardcoded values everywhere	Everything configurable via environment variables
README written as afterthought	README written first, before any code
No .env.example	Every required variable documented with examples
Manual setup, 20 steps	One setup script, under 5 minutes
No screenshots	Visual preview of every major screen
Outdated dependencies	Dependencies maintained and up to date
No documentation	Architecture, deployment, and customization guides

Advanced: Demo data and seeding

Applications that include realistic demo data convert better and get better reviews. Add a seed script:

# scripts/seed.sh
npm run db:seed:demo
# Creates: 3 demo users, 2 plans, sample analytics data, example teams

Document it in your README. Buyers can explore the full application experience before they start building.

vault.yaml Reference — every field explained
Publishing Guide — the full publishing process
Monetization — pricing applications appropriately
Product Categories — understand how Applications differ from Systems

Building Applications

On this page

Building Applications

On this page