Building something saleable inside the Claude Code ecosystem is different from shipping an app or a SaaS. Claude Skills and Claude Code Plugins are artifacts that an AI reads and executes — so the product is the specification of behavior as much as the code. This piece pulls together the lessons I've accumulated from shipping a few of each: the ones that turned into real revenue, and the ones that were "launched" and never sold.
This isn't a tutorial. It is a map covering how to find the niche, design the artifact, set a price, run the checkout, and keep the business alive. If you want to turn a small corner of the Claude ecosystem into a product that earns a few hundred to a few thousand dollars a month, this is the territory to walk.
Skills vs. Plugins — Which One to Ship
Claude Skills and Claude Code Plugins look similar from the outside; they behave quite differently as products.
Skills are knowledge-and-workflow packages loaded whenever Claude triggers them. They are mostly text and a few scripts, so distribution is light and the barrier for a user to try them is low. Their weakness is that they do not reach deeply into a runtime, so you sell domain knowledge and a disciplined output pattern, not raw capability.
Plugins wire directly into Claude Code itself — tools, slash commands, MCP servers. This is where you differentiate through integrations and custom runtime behavior. The cost is a steeper onboarding curve, so plugins tend to work best for users who already trust you enough to install something a little heavier.
A useful framing for indie builders:
- Ship a Skill when the value is "a professional always producing output in this exact form." Good examples: a contract-review skill, an e-commerce listing skill, a press-release editing skill.
- Ship a Plugin when the value is integration depth. Good examples: a Stripe invoicing workflow, an AWS CloudWatch log analysis suite, an iOS release-cut plugin.
Decide which one you're shipping by the density of the value you want to deliver. Information and style → Skills. Behavior and integration → Plugins.
Designing a Niche-First Skill
The gravity of AI products is toward "works for everyone." You have to fight it actively. Generic Skills compete with free official Skills, and the paid tier collapses to zero. What actually sells is a Skill that is undeniable for one specific audience.
The template I use to design a niche Skill has four steps.
Step 1: One role × one task. "E-commerce store owners × optimizing product title and description" — not "marketers × writing copy." The tighter the pair, the sharper the thing you're selling.
Step 2: Observe the real workflow. Sit next to the person you're designing for. Watch what files they keep open. Record the templates and rules they hold in their head. The Skill's job is to move that tacit knowledge into Claude, so you need to see the concrete files and forms.
Step 3: Lock a single output format. Skills that "vary depending on context" erode trust over time. A professional tool always produces the same shape — this is what makes it a product and not a toy.
Step 4: Pre-kill the bad outputs. Anything a domain pro would look at and say "that's amateur" should be explicitly banned in the Skill. The more of these prohibitions you codify, the closer the Skill feels to "having a senior sitting beside you."
A Skill designed this way will beat a generic Skill every time, because the user feels "I cannot do this job without this one specific Skill."
The File Structure of a Saleable Skill
Here is a simplified layout of one of the Skills I currently sell. The bones follow the Claude Skills spec, but every file is chosen with an eye to it being a product.
ec-product-description-pro/
├── SKILL.md # Entry point (required)
├── style_guide.md # The core voice and tone
├── banned_phrases.md # The forbidden output list
├── category_templates/ # Per-category templates
│ ├── fashion.md
│ ├── cosmetics.md
│ └── home_appliance.md
├── examples/ # Real input/output pairs
│ ├── input_001.json
│ ├── output_001.md
│ └── ...
├── scripts/
│ └── validate_output.py # Output validator
└── LICENSE
Keep SKILL.md short — trigger conditions and a summary. Move the real knowledge into style_guide.md and category_templates/. Stuffing everything into the entry point increases the chance Claude drops context when it loads.
banned_phrases.md is where the Skill's personality lives. "Always write in this register" and "never use soft qualifiers like 'might' or 'perhaps'" are the kind of rules that push the Skill away from generic AI prose and toward something that feels professional.
validate_output.py is optional, but a saleable Skill benefits from having one. A script that checks word counts, forbidden terms, and required fields is how you guarantee the quality floor — and that guarantee is a big part of what the user is paying for.
Pricing — Do Not Charge by the Hour
The most common indie pricing mistake is "my hourly rate × time spent." It is always wrong for information products. Skills and Plugins should be priced on the value the user captures, not on what they cost you to build.
The procedure I use:
- Estimate how much time the Skill saves per use (e.g., 30 minutes).
- Estimate the user's hourly cost (e.g., $30/hr → $15 per use).
- Estimate monthly usage (e.g., 20 uses/month → $300 of captured value).
- Set the monthly price at 10–20% of that captured value (e.g., $30–$60/month).
A price derived this way reflects what the user gains, not what you sweated. The moment this math converges, your monthly revenue will cross your hourly rate — and keep going.
Skills are nearly always better sold monthly than as a one-time purchase. One-time pricing kills your incentive to maintain the Skill and nags at the user ("will this keep getting better?"). Monthly pricing aligns both sides on continuous improvement.
Checkout — A Minimal Stack That Works
Neither Skills nor Plugins can charge on their own, so you bolt on an external payment layer. For a bootstrapping indie developer, Stripe + Cloudflare Workers is the quietest stack that works.
The flow:
- Landing page → Stripe Checkout.
- Stripe webhook hits a Cloudflare Worker, which mints a per-user access token.
- The
SKILL.mdREADME instructs the buyer to drop that token into an env var in their Claude Code setup. - On first use, the Skill calls a small validation endpoint; invalid token → the Skill politely stops.
Storing tokens and expiry in Cloudflare Workers KV is enough for a product at the few-thousand-a-month scale. Here is the shape of the validator:
// Cloudflare Workers validation endpoint
export default {
async fetch(request, env) {
const { token } = await request.json();
const record = await env.TOKENS.get(token, { type: 'json' });
if (!record || record.expires_at < Date.now()) {
return new Response(JSON.stringify({ valid: false }), { status: 403 });
}
return new Response(JSON.stringify({ valid: true, plan: record.plan }));
}
}From the Skill side, a small Python check calls this endpoint and aborts if the token is invalid. Do not over-engineer licensing — aim for "normal users pay without thinking; a determined attacker could work around it." For a $30/month product, that is the correct ceiling.
Getting to Your First 100 Customers
The single biggest indie failure mode is "build the product, then go look for buyers." I do it the other way around now: I talk to the audience before I build.
The process:
- Identify three to five communities (Discord, Slack, subreddits) where the target role hangs out.
- Find people who have said "I want to use AI for work but don't know how to start."
- DM them and describe the Skill you're considering. Ask if they'd use it.
- Offer the first ten respondents a half-price closed beta.
"Build before asking" is the fastest way to burn indie time and money. "Ask first" compresses the time between starting the project and the first paid customer from many months to a few weeks.
The Skill I run today had eight paying beta users locked in before launch, and did ~$150 in revenue on day one. The amount doesn't matter — the fact of launching into a live audience does, because it changes everything about how the improvement cycle starts.
Retention and the Biweekly Improvement Loop
For a monthly Skill, the metric that actually matters is churn, not MRR. If every new signup is matched by a cancellation, the business doesn't grow.
The trick to retention is giving users a reason to keep using it. I run a biweekly loop:
- Collect anonymized usage telemetry (frequency and patterns, never content).
- Reach out only to users whose usage has dropped, with a short survey.
- Roll the feedback into
style_guide.mdorbanned_phrases.md. - Email the whole customer base: "here's what's new this cycle."
Users who feel their feedback landed in the product stay. After six months of running this loop, my monthly churn sits under 3%. At $30/month × 3% churn, the simple LTV is over $1,000 per user — a very respectable number for a one-person product.
Write Down Your Exit Rules First
Mentally, the most important part of shipping an information product is deciding — on day one — when you will walk away.
My rules:
- If I don't have ten paying users three months in, I stop selling and release it free.
- If monthly churn stays above 7% for six straight months, I redesign the product.
- If I haven't shipped a meaningful update in six months, it stops being a product and becomes a free artifact.
Without these, you end up nursing a dud indefinitely because "it might still work." The mental space you get back when you close a failed product is where the next successful one gets built.
Turning Skills and Plugins into products means running the full cycle — design, price, checkout, improvement, and exit — as one connected system. The Claude ecosystem is still early enough that a clear, disciplined builder has real room to define a niche. Before you write a single line of code, write down who the user is and what you promise to deliver them. The rest of this map only works after that.