Stats
Actions
Tags
From market-feasibility
Takes a software product idea — described in plain text, a pitch document, a notes file, or a conversational description — and produces a comprehensive Market Feasibility Report. The report assesses the idea's viability across seven dimensions: technical, economic, legal/regulatory, operational, scheduling, market/commercial, and pricing strategy. This skill does NOT require a codebase. It works from an idea description alone, though it can optionally incorporate an existing repo, prototype, or design document if provided. Trigger phrases include: "feasibility study", "is this idea viable", "should I build this", "market feasibility", "can this work", "evaluate this idea", "assess this project", "business viability", "feasibility report", "will this sell", "is there a market for", or any time the user describes a software product concept and asks whether it's worth pursuing. This skill is also appropriate when the user pitches an idea and asks "what do you think?" — always consider whether a feasibility assessment would be valuable in that context.
How this skill is triggered — by the user, by Claude, or both
Slash command
/market-feasibility:market-feasibility-reportThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
A comprehensive framework for evaluating the viability of a software product idea across
A comprehensive framework for evaluating the viability of a software product idea across technical, economic, legal, operational, scheduling, and market dimensions — culminating in a full pricing strategy and go-to-market plan. Works from idea descriptions, pitch documents, or conversational input.
Unlike codebase analysis, this skill starts from an idea — which may be vague, partial, or spread across multiple inputs. The first job is to crystallize the idea into something concrete enough to evaluate.
The user may provide any of the following:
If a file path or URL is provided, read it:
# For a local file or directory
ls -la <path>
cat <path> # if it's a document
# For a GitHub URL (early prototype)
git clone --depth=1 <url> /tmp/feasibility-analysis-target
After consuming all inputs, extract the following. If the user hasn't provided enough detail, ask clarifying questions — but batch them into a single round. Do not ask more than 5-7 questions at once. Mark unknown fields as "TBD — needs user input" and proceed with reasonable assumptions where possible.
| Field | Answer |
|---|---|
| Working product name | |
| One-sentence elevator pitch | |
| Problem being solved | |
| Who has this problem? (target users) | |
| Proposed solution approach | |
| Product category | (CLI / desktop app / web app / SaaS / API / library / mobile app / marketplace / hardware+software) |
| Deployment model | (self-hosted / cloud / local / hybrid / app store) |
| Revenue intent | (venture-backed / bootstrapped / side project / open source / internal tool) |
| Existing assets | (nothing yet / wireframes / prototype / MVP / partial codebase) |
| Solo founder or team? | |
| Target launch timeframe | |
| Budget range | (bootstrapping / <$10K / $10K-$50K / $50K-$250K / $250K+) |
Before proceeding, explicitly state every assumption you are making about the idea. The user must be able to see and correct these before the analysis proceeds. Format:
Assumptions made for this analysis:
- [assumption] — assumed because [reason]
- [assumption] — assumed because [reason] ...
If any of these are wrong, let me know and I'll adjust the analysis.
This phase determines whether there is a real market for the idea and whether the product can capture meaningful demand.
Answer these critical questions using web research:
Is this a real problem? Search for people complaining about this problem online (forums, Reddit, Twitter/X, Hacker News, Stack Overflow, Quora). Quantify signal:
How are people solving this today? (existing solutions, workarounds, manual processes)
Why haven't existing solutions fully solved it? (too expensive, too complex, wrong audience, missing features, bad UX)
Is the problem growing or shrinking? Look for trends:
Estimate the addressable market using a bottom-up approach (preferred) with a top-down sanity check:
Bottom-Up (primary):
Number of potential users/companies with this problem × Average revenue per user = SAM
SAM × Realistic capture rate (1-5% for startups) = SOM
Top-Down (sanity check):
Total market spending in the category × % addressable by this product type = TAM
TAM × % reachable by a new entrant = SAM
Present as a table:
| Metric | Estimate | Methodology |
|---|---|---|
| TAM (Total Addressable Market) | $X | [how calculated] |
| SAM (Serviceable Addressable Market) | $Y | [how calculated] |
| SOM (Serviceable Obtainable Market) | $Z | [how calculated] |
Flag if the SOM is below $100K/year — this may be a viable side project but not a sustainable business unless costs are near zero.
Search the web for direct and indirect competitors:
# Search queries to run:
# "[problem description] software"
# "[product category] tools [year]"
# "[product name] alternatives" (if a known competitor exists)
# "[target user] [problem] solution"
Build a competitor matrix:
| Competitor | Type | Price | Strengths | Weaknesses | Market Position |
|---|---|---|---|---|---|
| [name] | Direct / Indirect | $X | Leader / Challenger / Niche |
Assess:
Identify 3-5 realistic buyer personas. For each:
Before investing in a name, verify it's defensible and not crowded.
Run all of the following using web search. For each, record findings:
1. Domain Availability Search 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 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
Generate 5-10 alternative name suggestions that:
IMPORTANT: Flag name risk prominently in the Executive Summary if YELLOW or RED.
This phase determines whether the product can actually be built with available technology, skills, and resources.
Based on the idea description, identify:
| Requirement | Details | Complexity |
|---|---|---|
| Core functionality | [what must the product do at minimum?] | LOW / MEDIUM / HIGH |
| Data storage needs | [type, volume, sensitivity] | LOW / MEDIUM / HIGH |
| Integration requirements | [APIs, third-party services, protocols] | LOW / MEDIUM / HIGH |
| Performance requirements | [latency, throughput, concurrency] | LOW / MEDIUM / HIGH |
| Security requirements | [auth, encryption, compliance] | LOW / MEDIUM / HIGH |
| Infrastructure needs | [hosting, CDN, scaling] | LOW / MEDIUM / HIGH |
| Platform targets | [web, mobile, desktop, CLI, API] | LOW / MEDIUM / HIGH |
Propose a technology stack with rationale:
| Layer | Recommendation | Why | Alternatives |
|---|---|---|---|
| Frontend | |||
| Backend | |||
| Database | |||
| Infrastructure | |||
| Auth | |||
| Payments | |||
| Monitoring | |||
| CI/CD |
Consider:
Identify specific technical risks:
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| [e.g., "Real-time sync is complex"] | HIGH/MED/LOW | HIGH/MED/LOW | [approach] |
| [e.g., "ML model accuracy unknown"] | |||
| [e.g., "Third-party API dependency"] |
Flag any technical blockers — things that could make the project impossible:
For each major component, evaluate whether to build custom or use existing services:
| Component | Build | Buy/Use | Recommendation | Rationale |
|---|---|---|---|---|
| Auth system | Custom | Auth0/Clerk/Supabase Auth | ||
| Payments | Custom | Stripe/Paddle | ||
| Custom | SendGrid/Resend | |||
| [etc.] |
Define the minimum viable product — the smallest version that tests the core value proposition:
Estimate MVP scope in terms of:
This phase models the economics — can this product make money, and how much investment does it require?
Estimate costs to reach MVP and then v1:
MVP (Minimum Viable Product):
| Cost Category | Low Estimate | High Estimate | Assumptions |
|---|---|---|---|
| Development (labor) | [hours × rate] | ||
| Design (UI/UX) | |||
| Infrastructure (first 6 months) | |||
| Third-party services/APIs | |||
| Legal (incorporation, terms, privacy) | |||
| Domain & branding | |||
| Total MVP Cost |
v1.0 (Market-ready product):
| Cost Category | Low Estimate | High Estimate | Assumptions |
|---|---|---|---|
| Additional development | |||
| QA & testing | |||
| Documentation | |||
| Marketing launch | |||
| Total v1.0 Cost |
Adjust estimates based on the user's situation:
| Cost | Month 1-3 | Month 4-6 | Month 7-12 | Year 2 |
|---|---|---|---|---|
| Hosting/infra | ||||
| Third-party APIs | ||||
| Support tools | ||||
| Marketing/ads | ||||
| Team (if any) | ||||
| Legal/accounting | ||||
| Monthly Total |
Using the demand curve from Phase 1 personas and WTP estimates:
| Scenario | Month 3 | Month 6 | Month 12 | Year 2 |
|---|---|---|---|---|
| Conservative | ||||
| Moderate | ||||
| Optimistic |
State assumptions clearly for each scenario (conversion rates, growth rates, churn rates, ARPU).
Break-even point = Total Fixed Costs / (Revenue per Customer - Variable Cost per Customer)
| Metric | Value |
|---|---|
| Monthly fixed costs | $X |
| Revenue per customer (ARPU) | $Y/mo |
| Variable cost per customer | $Z/mo |
| Contribution margin | $Y - $Z |
| Customers needed to break even | X / (Y - Z) |
| Months to break even (moderate scenario) | [estimate] |
| Metric | Year 1 | Year 2 | Year 3 |
|---|---|---|---|
| Total investment to date | |||
| Cumulative revenue | |||
| Net position | |||
| ROI % |
Based on the financial model, assess:
This phase identifies legal requirements, risks, and compliance obligations.
| Question | Assessment |
|---|---|
| Recommended business entity | (LLC / C-Corp / S-Corp / Sole Prop — and why) |
| IP protection needed | (patents / trade secrets / copyright / trademark) |
| Open source considerations | (if applicable: license choice, CLA needs, dual licensing) |
| Terms of Service required? | Yes / No — complexity level |
| Privacy Policy required? | Yes / No — complexity level |
Identify all applicable regulations based on:
| Regulation | Applies? | Impact | Compliance Cost | Timeline |
|---|---|---|---|---|
| GDPR | ||||
| CCPA/CPRA | ||||
| PCI-DSS | ||||
| HIPAA | ||||
| SOC 2 | ||||
| App Store Guidelines | ||||
| [industry-specific] |
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
| Patent infringement | [prior art search results] | ||
| Trademark dispute | [from brand clearance in 1E] | ||
| Data breach liability | [security measures] | ||
| Regulatory non-compliance | [compliance plan] | ||
| Terms of service disputes | [standard terms] | ||
| Open source license conflicts | [license audit] |
Estimate legal costs for launch readiness:
| Item | DIY Cost | Lawyer Cost | Priority |
|---|---|---|---|
| Entity formation | $50-$500 | $500-$2,000 | MUST |
| Terms of Service | $0 (template) | $1,000-$3,000 | MUST |
| Privacy Policy | $0 (template) | $500-$2,000 | MUST |
| Trademark filing | $250-$350 | $1,000-$2,000 | SHOULD |
| Patent search/filing | N/A | $5,000-$15,000 | MAYBE |
| Compliance audit | N/A | $3,000-$20,000 | [depends] |
This phase assesses whether the founder/team can realistically build, launch, and sustain this product.
| Role | Needed? | Available? | Gap? | Solution |
|---|---|---|---|---|
| Technical founder / lead developer | ||||
| Designer (UI/UX) | ||||
| Marketing / growth | ||||
| Sales (if B2B) | ||||
| Customer support | ||||
| DevOps / infrastructure | ||||
| Legal / compliance |
What must be in place to run this product post-launch?
| Requirement | Complexity | Current Readiness |
|---|---|---|
| Customer support channel | LOW / MED / HIGH | Ready / Needs Setup / Not Started |
| Monitoring & alerting | ||
| Billing & invoicing | ||
| Onboarding flow | ||
| Documentation | ||
| Backup & disaster recovery | ||
| Incident response process | ||
| Update/deploy pipeline |
At what user counts do operations fundamentally change?
| Users | Operational Impact | Action Required |
|---|---|---|
| 1-100 | Founder handles everything | [current state] |
| 100-1,000 | Support volume becomes significant | [hire support / build self-serve] |
| 1,000-10,000 | Infrastructure scaling needed | [dedicated DevOps / managed services] |
| 10,000+ | Team structure required | [multiple hires, process formalization] |
Be honest about bandwidth:
This phase determines whether the project can be completed within a reasonable timeframe and identifies critical path dependencies.
Estimate a realistic timeline with milestones:
| Phase | Duration | Milestone | Dependencies |
|---|---|---|---|
| Research & Planning | [weeks] | PRD complete, tech decisions finalized | None |
| Design | [weeks] | UI/UX mockups approved | PRD |
| MVP Development | [weeks] | Core features working, deployable | Design |
| Alpha Testing | [weeks] | Internal testing complete, critical bugs fixed | MVP |
| Beta / Early Access | [weeks] | External users testing, feedback collected | Alpha |
| v1.0 Launch | [weeks] | Public launch, marketing push | Beta |
| Post-Launch Iteration | [ongoing] | Feature expansion based on feedback | v1.0 |
Identify the longest dependency chain — this is the minimum calendar time to launch:
[Critical path: A → B → C → D = X weeks minimum]
Identify parallelizable work that can happen simultaneously:
| Risk | Impact on Timeline | Likelihood | Mitigation |
|---|---|---|---|
| Scope creep | +2-8 weeks | HIGH | Strict MVP definition |
| Technical unknowns | +1-4 weeks | MEDIUM | Spike/prototype early |
| Third-party dependency delays | +1-2 weeks | LOW | Identify alternatives |
| Founder availability changes | +2-12 weeks | [depends] | Buffer in schedule |
| Hiring delays (if needed) | +4-8 weeks | MEDIUM | Start recruiting early |
Rate schedule feasibility:
FEASIBLE — Timeline is realistic given team, scope, and resources TIGHT — Achievable but requires focused execution and no major setbacks AT RISK — Timeline is aggressive; recommend extending or reducing scope INFEASIBLE — Cannot be done in the proposed timeframe; recommend re-scoping
If AT RISK or INFEASIBLE, provide specific recommendations:
This phase applies the full pricing framework from the software valuation methodology. It builds on the customer personas, competitive landscape, and financial model from earlier phases.
Using personas from Phase 1D, sketch the demand curve:
| Price Point | Likely Buyers | Estimated Revenue |
|---|---|---|
| Free | All personas | $0 |
| $X (low) | Most personas | $X x N |
| $Y (mid) | Some personas | $Y x M |
| $Z (high) | Premium/enterprise only | $Z x P |
| $W (too high) | Nobody | $0 |
Identify the revenue-maximizing price band.
Evaluate each model for fit (score as HIGH / MEDIUM / LOW):
| Model | Fit | Rationale |
|---|---|---|
| One-time perpetual license | ||
| Subscription (monthly/annual) | ||
| Freemium (free + paid upgrade) | ||
| Usage-based / metered | ||
| Gillette (razor/blade) | ||
| Open core (OSS + commercial) | ||
| Consulting / services wrapper | ||
| Marketplace / transaction fee |
RECOMMENDATION: State the single best model (or hybrid) with rationale.
| Tier Name | Target Persona | Key Differentiators | Suggested Price |
|---|---|---|---|
| Free / Community | $0 | ||
| Starter / Indie | $X | ||
| Pro / Team | $Y | ||
| Enterprise | $Z or "Contact us" |
| Threshold | Typical Rule | Product's Position |
|---|---|---|
| < $10 | Personal card, no approval | |
| $10-$50 | Personal card, may expense | |
| $50-$999 | Boss's card, verbal OK | |
| $1,000-$4,999 | Formal approval required | |
| $5,000-$24,999 | Department head approval | |
| $25,000+ | CEO / board visibility |
What does the proposed price communicate about the product?
Identify natural bundles:
Does this product have network effects?
For desktop/offline products:
| Timeframe | Strategy | Price | Rationale |
|---|---|---|---|
| Pre-launch | |||
| Day 1 | |||
| Month 3 | |||
| Month 6 | |||
| Month 12 |
Include early adopter pricing, introductory offers, and price escalation plan.
Perceived Value Enhancement:
Reference Point Management:
Channel Strategy:
Key Messaging Pillars:
If the founder's goals include building developer credibility, GitHub traction, or community-driven growth (not just revenue), include this section. Skip if the product is purely commercial/closed-source.
Assess whether open-sourcing makes strategic sense:
| Factor | Assessment |
|---|---|
| Is the product value in code or in data/network? | Code = OSS friendly; Data/Network = keep proprietary |
| Does the product benefit from community contributions? | More adapters/integrations = YES |
| Is there a hosted-service monetization path? | Free code + paid hosting = viable OSS business |
| Does the founder want GitHub credibility? | If yes, OSS is the fastest path |
Key insight: The most-starred repos ship frameworks and toolkits, not finished apps. If the product can be restructured as a pluggable toolkit with a reference implementation, it will attract more contributors and stars than a monolithic app.
Propose a repo structure that makes contributing easy:
Outline a concrete launch and growth plan:
Pre-launch (before v1.0):
Launch (week 1):
Growth (month 1-3):
Ecosystem (month 3-6):
If the product is web-based, assess whether a browser extension or CLI would increase organic discovery and GitHub traction:
| Metric | Target (Month 3) | Target (Month 6) |
|---|---|---|
| GitHub stars | 100-300 | 500-1,000 |
| Contributors | 5-10 | 15-25 |
| Forks | 20-50 | 50-150 |
| PR merge time | <48 hours | <48 hours |
| Open good first issue count | 5-10 (always) | 5-10 (always) |
This phase consolidates all risks from previous phases and delivers the final verdict.
Gather the top risks from every phase into a single register:
| # | Risk | Source Phase | Likelihood | Impact | Severity | Mitigation |
|---|---|---|---|---|---|---|
| 1 | H/M/L | H/M/L | CRITICAL/HIGH/MED/LOW | |||
| 2 | ||||||
| ... |
Severity scoring:
| Helpful | Harmful | |
|---|---|---|
| Internal | Strengths: [list] | Weaknesses: [list] |
| External | Opportunities: [list] | Threats: [list] |
Rate each dimension on a 1-5 scale:
| Dimension | Score (1-5) | Key Finding |
|---|---|---|
| Market Feasibility | [one-line summary] | |
| Technical Feasibility | [one-line summary] | |
| Financial Feasibility | [one-line summary] | |
| Legal Feasibility | [one-line summary] | |
| Operational Feasibility | [one-line summary] | |
| Schedule Feasibility | [one-line summary] | |
| Pricing Viability | [one-line summary] | |
| Overall Score | /5 |
Scoring guide:
Deliver one of four verdicts:
GO — The idea is viable across all dimensions. Proceed with confidence. Provide a recommended first action.
GO WITH CONDITIONS — The idea is viable but specific conditions must be met first. List the conditions explicitly (e.g., "viable only if you can hire a backend developer within 60 days" or "viable only if legal review confirms no IP conflict").
PIVOT RECOMMENDED — The core idea has merit but the current approach has fatal flaws. Suggest specific pivots (different market segment, different delivery model, different pricing, different technical approach).
NO-GO — The idea is not viable in its current form. Explain which dimensions fail and why. If there's a path to viability, describe it. If not, say so directly.
Generate a complete Market Feasibility Report as a structured Markdown document.
# Market Feasibility Report
## [Product Name]
Generated: [date]
---
## Executive Summary
[5-7 sentence overview: what the idea is, the key findings across all dimensions,
the overall feasibility score, and the go/no-go recommendation. If there are critical
risks (brand name RED, legal blockers, etc.), flag them here prominently.]
---
## Feasibility Scorecard
[Scorecard table from 8C — placed early for quick scanning]
---
## Idea Profile
[Extraction checklist from 0B + stated assumptions from 0C]
---
## Market & Commercial Feasibility
### Problem Validation
[From 1A]
### Market Sizing
[TAM/SAM/SOM from 1B]
### Competitive Landscape
[Competitor matrix from 1C]
### Customer Segments
[Personas from 1D]
### Brand Name Clearance
[Full clearance report from 1E]
---
## Technical Feasibility
### Requirements Analysis
[From 2A]
### Recommended Stack
[From 2B]
### Technical Risks
[From 2C]
### Build vs. Buy
[From 2D]
### MVP Definition
[From 2E]
---
## Financial Feasibility
### Development Costs
[From 3A]
### Operating Costs
[From 3B]
### Revenue Projections
[From 3C]
### Break-Even Analysis
[From 3D]
### ROI Projections
[From 3E]
### Funding Assessment
[From 3F]
---
## Legal & Regulatory Feasibility
### Business Structure & IP
[From 4A]
### Regulatory Compliance
[From 4B]
### Legal Risks
[From 4C]
### Legal Budget
[From 4D]
---
## Operational Feasibility
### Team Assessment
[From 5A]
### Operational Requirements
[From 5B]
### Scalability Plan
[From 5C]
### Founder Capacity
[From 5D]
---
## Schedule Feasibility
### Project Timeline
[From 6A]
### Critical Path
[From 6B]
### Timeline Risks
[From 6C]
### Schedule Verdict
[From 6D]
---
## Pricing & Go-to-Market Strategy
### Demand Curve Analysis
[From 7A]
### Pricing Model Recommendation
[From 7B]
### Tier Structure
[From 7C]
### Launch Pricing Strategy
[From 7I]
### Marketing Strategy
[From 7J]
### Bundling Opportunities
[From 7F]
---
## Open Source & Community Strategy (if applicable)
### Open Source Positioning
[From 7K-1]
### Architecture for Contribution
[From 7K-2]
### GitHub Traction Playbook
[From 7K-3]
### Browser Extension / CLI Strategy
[From 7K-4]
### Community Health Metrics
[From 7K-5]
---
## Risk Analysis
### Consolidated Risk Register
[From 8A]
### SWOT Analysis
[From 8B]
---
## Recommendation
### Verdict: [GO / GO WITH CONDITIONS / PIVOT RECOMMENDED / NO-GO]
[Detailed rationale — reference specific findings from each phase]
### Conditions (if applicable)
[Numbered list of conditions that must be met]
### Recommended Next Steps
[Ordered action list: what to do first, second, third — make these concrete and
time-bound, not vague]
---
## Davidson Pricing Checklist
[Completed checklist tailored to this product]
---
## Appendix: Assumptions & Methodology
[All assumptions declared in Phase 0C + any additional assumptions made during analysis]
[Note which findings are based on web research vs. estimation vs. industry benchmarks]
After generating the report:
feasibility-report-[product-name].mdThis skill applies the following frameworks:
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/claude-code-market-feasibility --plugin market-feasibility