Stats
Actions
Tags
From software-valuation
Analyzes a software product from a local folder path OR a GitHub URL and produces a comprehensive, structured pricing and marketing strategy report. Use this skill any time a user wants to price their software, evaluate monetization options, build a go-to-market strategy, or understand what their product is worth to different customer segments. Trigger phrases include: "price my software", "pricing strategy for my project", "how should I charge for this", "what should I sell this for", "marketing strategy for my app", "monetization plan", "help me price [product name]", or any time the user provides a GitHub URL or local folder and asks about pricing, selling, or monetizing. This skill is also appropriate when the user just shares a repo and asks "what do you think?" — always consider whether pricing guidance would be valuable in that context.
How this skill is triggered — by the user, by Claude, or both
Slash command
/software-valuation:software-pricing-strategyThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A four-phase framework for analyzing any software product and delivering a concrete,
A four-phase framework for analyzing any software product and delivering a concrete, evidence-based pricing and marketing strategy. Works with local directories or GitHub URLs.
Before doing anything else, determine the input type:
If the user provides a local folder (e.g. ~/projects/myapp or /home/user/my-app):
ls -la <path>
Proceed directly to Phase 1 from that directory.
If the user provides a GitHub URL (e.g. https://github.com/user/repo):
# Extract owner/repo from URL
# Clone to a temp working directory
git clone --depth=1 <url> /tmp/pricing-analysis-target
cd /tmp/pricing-analysis-target
If the clone fails (private repo, bad URL), inform the user and ask for a local path or a zip export instead.
If neither is provided, ask: "Please provide either a local folder path or a GitHub URL for the software you'd like to analyze."
Read the repository systematically. The goal is to understand what the software is, who it is for, and what problem it solves. Do not guess — read the actual files.
Run this inventory first:
find . -maxdepth 3 \( \
-name "README*" -o -name "readme*" \
-o -name "DESCRIPTION*" \
-o -name "package.json" \
-o -name "pyproject.toml" -o -name "setup.py" -o -name "setup.cfg" \
-o -name "Cargo.toml" \
-o -name "go.mod" \
-o -name "Gemfile" \
-o -name "composer.json" \
-o -name "*.csproj" \
-o -name "pom.xml" \
-o -name "build.gradle" \
-o -name "CHANGELOG*" -o -name "changelog*" \
-o -name "LICENSE*" \
-o -name "PRICING*" -o -name "pricing*" \
-o -name "MONETIZATION*" \
-o -name "docs" -type d \
-o -name "landing*" -o -name "marketing*" \
\) 2>/dev/null | head -60
Then read each found file. Pay special attention to:
Get a high-level sense of what the software actually does:
# Count lines of code by language
find . -name "*.py" -o -name "*.ts" -o -name "*.tsx" -o -name "*.js" \
-o -name "*.rs" -o -name "*.go" -o -name "*.rb" -o -name "*.cs" \
2>/dev/null | xargs wc -l 2>/dev/null | tail -1
# Top-level directory structure
ls -d */ 2>/dev/null || ls
# Dependency count (signals product complexity and maturity)
cat package.json 2>/dev/null | python3 -c "
import json,sys
d=json.load(sys.stdin)
deps=len(d.get('dependencies',{}))
dev=len(d.get('devDependencies',{}))
print(f'Runtime deps: {deps}, Dev deps: {dev}')
" 2>/dev/null || true
After reading the files, synthesize the following. Do not proceed to Phase 2 until you can answer all of these (even if the answer is "unclear / not documented"):
| Field | Answer |
|---|---|
| Product Name | |
| One-sentence description | |
| Primary language / stack | |
| Product category | (CLI tool / desktop app / web app / SaaS / API / library / SDK / game / mobile app) |
| Deployment model | (self-hosted / cloud SaaS / local / hybrid) |
| Open source? | (MIT / GPL / proprietary / source-available) |
| Maturity stage | (prototype / alpha / beta / v1+ / mature) |
| Target user (primary) | |
| Target user (secondary) | |
| Core problem solved | |
| Top 3 features | |
| Integration ecosystem | (standalone / plugs into X, Y, Z) |
| Existing monetization? | (none / freemium / paid / OSS with pro tier) |
| Docs quality | (none / minimal README / full docs site) |
| Known competitors | (from README, docs, or pkg keywords) |
Before pricing a product, verify the product name is defensible and not crowded. A name collision creates real business risk — trademark disputes, App Store rejection, customer confusion, or (as in real cases) a buyer perceiving conflict of interest with an employee's surname.
Run all of the following searches using web search. For each, record what you find:
1. Domain Availability Search for the product name across key TLDs:
2. App Store Presence
3. Trademark Registry Search
4. Copyright Registry
5. General Web Presence
6. Phonetic / Visual Similarity Scan
| Check | Findings | Risk Level |
|---|---|---|
| .com domain | Available / Taken by [X] | LOW / MEDIUM / HIGH |
| Other TLDs | [summary] | LOW / MEDIUM / HIGH |
| Apple App Store | [N] results, [M] exact/close matches | LOW / MEDIUM / HIGH |
| Google Play Store | [N] results, [M] exact/close matches | LOW / MEDIUM / HIGH |
| USPTO trademarks | [N] live marks in relevant classes | LOW / MEDIUM / HIGH |
| EUIPO trademarks | [N] live marks | LOW / MEDIUM / HIGH |
| Copyright records | [findings] | LOW / MEDIUM / HIGH |
| Web presence | [N] competing products | LOW / MEDIUM / HIGH |
| Sound-alikes | [list] | LOW / MEDIUM / HIGH |
| Look-alikes | [list] | LOW / MEDIUM / HIGH |
Rate the name with one of three levels:
GREEN — Name is clear across all registries, minimal competition, safe to invest in branding YELLOW — Some conflicts exist but in different industries/classes; proceed with caution RED — Crowded namespace, active trademarks in same class, or high confusion risk
When the namespace is crowded, generate 5–10 alternative name suggestions that:
IMPORTANT: Flag name risk prominently in the Executive Summary if YELLOW or RED. A great pricing strategy is worthless if the product faces a C&D letter on launch day.
This phase translates Discovery data into a structured view of the market. Follow each section in order.
Identify 3–5 realistic buyer personas for this product. For each persona, estimate:
Apply the Davidson framework: "A rational buyer should pay up to the dollar value of the benefit they receive." But humans are not rational — perceived value matters more than objective value. For each persona, note whether perceived value is likely higher or lower than objective value, and why.
Using the personas from 2A, sketch a rough demand curve table:
| Price Point | Likely Buyers | Estimated Revenue |
|---|---|---|
| Free | All personas | $0 |
| $X (low) | Most personas | $X × N |
| $Y (mid) | Some personas | $Y × M |
| $Z (high) | Premium/enterprise only | $Z × P |
| $W (too high) | Nobody | $0 |
Identify the revenue-maximizing price band — this is the row with the largest estimated revenue, and becomes the baseline for your recommendation.
Answer these questions:
Use these reference points to determine whether the product needs to differentiate upward (justify a premium), match the market (compete on features), or own the low end (race to win on accessibility/price).
For each primary persona:
If switching costs are high: pricing must overcome them — free trials, migration tools, money-back guarantees, or import compatibility are critical.
If switching costs are low: price wars are a real risk. Differentiation via brand, community, or unique features becomes essential.
Search the web for direct competitors if internet is available:
# If web_search tool is available, search for:
# "[product category] pricing [year]"
# "[product name] alternatives"
# "[primary keyword from README] software pricing"
Build a competitor table:
| Competitor | Price Model | Entry Price | Top Tier | Notes |
|---|---|---|---|---|
| Competitor A | Freemium | Free | $X/mo | |
| Competitor B | One-time | $Y | $Z (pro) | |
| Competitor C | Per-seat | $A/seat | Enterprise |
Identify the price floor (cheapest credible competitor) and price ceiling (most expensive established player) for this category.
Apply each framework from the Davidson model. Score each one as Recommended / Consider / Skip for this specific product.
Evaluate these models for fit:
One-time perpetual license
Subscription (monthly/annual)
Freemium (free base + paid upgrade)
Usage-based / metered pricing
Gillette / razor-blade model
Open core (OSS + commercial)
Consulting / services wrapper
RECOMMENDATION: State the single best model (or hybrid) with a one-paragraph rationale.
Can this product be offered in multiple tiers? For each potential tier, specify:
| Tier Name | Target Persona | Key Differentiators | Suggested Price |
|---|---|---|---|
| Free / Community | (who gets this?) | (what's included / excluded?) | $0 |
| Starter / Indie | (who?) | (what features unlock?) | $X |
| Pro / Team | (who?) | (what features?) | $Y |
| Enterprise / Business | (who?) | (SSO, SLA, audit, custom) | $Z or "Contact us" |
Versioning warnings to flag if applicable:
Identify any natural bundles:
For each bundle candidate, apply the bundling revenue math:
Does this product have network effects? (i.e., does its value increase as more people use it?)
Examples: collaboration features, shared templates, community marketplaces, public leaderboards, integrations that require other users to also use the tool.
If YES: Free pricing at launch is strongly recommended to hit the adoption tipping point. Monetize post-tipping-point via premium features or enterprise tier.
If NO: Standard demand-curve pricing applies. Don't give away value unnecessarily.
For desktop/offline software:
Identify which organizational spending thresholds the pricing should target or avoid:
| Threshold | Typical Rule | Implication |
|---|---|---|
| < $10 | Personal card, no approval | Impulse buy — maximize volume |
| $10–$50 | Personal card, may expense | Low friction — still impulse adjacent |
| $50–$999 | Boss's card, verbal OK | Needs clear ROI justification |
| $1,000–$4,999 | Formal approval required | Needs champion inside org |
| $5,000–$24,999 | Department head approval | Enterprise sales motion required |
| $25,000+ | CEO / board visibility | Long sales cycle, legal review |
Recommendation: State whether the product should price just under a threshold or whether crossing a threshold is justified by the product's enterprise readiness.
What does the proposed price communicate about the product?
Assess whether the recommended price sends the right signal for this product's brand positioning and target buyer.
Generate a complete Software Pricing & Marketing Strategy Report as a structured
Markdown document. Save it as pricing-strategy-report.md in /home/claude/ then copy
to /mnt/user-data/outputs/.
# Pricing & Marketing Strategy Report
## [Product Name]
Generated: [date]
---
## Executive Summary
[3–5 sentence overview of the product, the market opportunity, and the top recommendation]
---
## Product Profile
[Completed Discovery table from Phase 1C]
---
## Brand Name Clearance
[Clearance report table from Phase 1D]
[Overall risk assessment: GREEN / YELLOW / RED]
[Alternative name suggestions if applicable]
---
## Customer Segments
[3–5 personas with WTP estimates and value analysis]
---
## Market Landscape
[Competitor table + reference point analysis]
[Price floor and ceiling]
---
## Demand Curve Analysis
[Demand curve table with estimated revenue at each price point]
[Revenue-maximizing price band identified]
---
## Pricing Model Recommendation
### Primary Model: [Name]
[Rationale paragraph]
### Tier Structure
[Versioning table]
### Bundling Opportunities
[Bundle analysis]
---
## Switching Costs & Positioning
[How to overcome switching costs]
[Key differentiators to promote]
---
## Launch Pricing Strategy
[What to charge on day 1]
[What to change at 6 months]
[What to change at 12 months]
[How to handle early adopter pricing]
---
## Marketing Strategy
### Perceived Value Enhancement
[Specific tactics for this product — personality, tribe, demos, content, etc.]
### Reference Point Management
[Which comparisons to encourage, which to avoid]
### Channel Strategy
[How to sell: web-only, marketplace, direct, resellers, OSS community]
### Key Messaging Pillars
[3 messages that justify the price and differentiate from alternatives]
---
## Risk Flags
[Specific pricing pitfalls to watch for this product]
[e.g., price war risk, cannibalization risk, enterprise threshold issues]
---
## Pricing Checklist
[Completed version of the Davidson checklist tailored to this product]
---
## Recommended Next Steps
[Ordered action list: what to do first, second, third]
After generating the report:
/mnt/user-data/outputs/pricing-strategy-report.mdpresent_filesThis skill applies the following frameworks, drawn from Neil Davidson's Don't Just Roll the Dice and standard SaaS/software monetization research:
Provides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
npx claudepluginhub frobinson47/solo-dev-suite --plugin software-valuation