Feasibility Study

Feasibility Study

Perform a comprehensive product feasibility study. Analyze the product across five dimensions (TELOS), estimate effort and cost, assess risks, and produce a structured report with a go/no-go recommendation.

Depth Modes

Parse $ARGUMENTS for --depth flag. Default to standard if not specified.

Phase 0: Parse Input and Configure

1. Parse $ARGUMENTS to extract:
   • Product name or URL (first positional argument)
   • Depth mode (--depth quick|standard|deep, default: standard)
2. If a URL is provided, fetch it with WebFetch to understand the product
3. If a product description is provided, confirm your understanding
4. Print: Starting feasibility study: {product} | Depth: {mode}

Phase 1: Discovery

Ask the user 3-5 targeted questions to understand the opportunity. Use AskUserQuestion for each. Smart-skip: if the URL/description already answers a question, skip it and state what you inferred.

Required context (must have all before proceeding):

1. Product: What is the product? What does it do? (pre-fill from URL analysis)
2. Users: Who is the target user? What problem does it solve for them?
3. Business model: How will it make money? (SaaS, marketplace, one-time, etc.)
4. Constraints: Budget range, timeline expectations, team size/skills available?
5. Success metrics: What does success look like? Scale targets?

After gathering answers, print a brief summary:

## Understanding
- Product: ...
- Target users: ...
- Business model: ...
- Constraints: ...
- Success metrics: ...

Gate 1: Sufficient Context

Verify you have minimum viable context to proceed. Checklist:

• Product is clearly defined
• Target user is identified
• Business model is understood (or explicitly "to be determined")
• At least one constraint is known

If any critical gap exists, ask ONE targeted follow-up question. Do not proceed until the checklist passes.

Phase 2: Research

Skip this phase for --depth quick

Use WebSearch to research:

1. Competitive landscape: Find 3-5 direct competitors or similar products
2. Market signals: Market size indicators, growth trends, recent funding
3. Technical precedents: Open source projects, published architectures, known challenges

For each competitor found, note: name, URL, pricing, key differentiators.

If WebSearch is unavailable, note the limitation and proceed with the information provided by the user. Do NOT block on research availability.

Print a brief research summary before proceeding.

Phase 3: TELOS Analysis

Analyze each dimension. Read the corresponding reference file on demand. Score each dimension 1-5 and provide evidence for the score.

3a. Technical Feasibility

Read references/technical-analysis.md for the framework.

Analyze:

• Architecture complexity: Classify as Simple / Moderate / Complex / Extreme
• Core components: List major technical components needed
• Technology stack: Recommend stack, flag any unproven technologies
• Integration complexity: External APIs, data sources, third-party services
• Scalability path: What changes at 10x, 100x scale
• Technical unknowns: What needs prototyping or proof-of-concept

Output: Technical Feasibility Score (1-5) with one-paragraph rationale.

3b. Economic Feasibility

Read references/cost-estimation.md for frameworks and rate cards.

For quick mode: Use T-shirt sizing only. For standard mode: Use function point estimation. For deep mode: Run scripts/estimate.py with COCOMO parameters.

Estimate three separate dimensions:

1. Effort (person-months): Total work regardless of who does it
2. Calendar time (months): Wall-clock time based on team size
3. Cash cost ($): Actual money spent — founder sweat equity = $0

Break down by:

• Development effort: By component/phase, with AI adjustment
• Team composition: Founders (sweat equity) vs. contractors (cash cost)
• Infrastructure cost: Monthly/annual hosting, third-party services
• Operating cost: Year 1, Year 2, Year 3 projections
• Hidden costs: Walk through the hidden costs checklist (mandatory)
• Revenue projection: Based on business model and market size
• ROI analysis: Payback period, 3-year ROI

Script supports team configuration:

# Solo founder + Claude Code, no cash cost
echo '{"operation": "function_points", "unadjusted_fp": 200, "ai_level": "very_high", "contractor_count": 0}' | python3 ${CLAUDE_SKILL_DIR}/scripts/estimate.py

# Founder + 1 contractor at $10K/mo
echo '{"operation": "function_points", "unadjusted_fp": 200, "ai_level": "high", "contractor_count": 1, "contractor_rate": 10000}' | python3 ${CLAUDE_SKILL_DIR}/scripts/estimate.py

All estimation script operations support AI productivity adjustment. Always ask the user about their AI tooling and apply the appropriate multiplier:

# With AI assistance level (named)
echo '{"operation": "cocomo", "kloc": <kloc>, "mode": "semi-detached", "ai_level": "high"}' | python3 ${CLAUDE_SKILL_DIR}/scripts/estimate.py

# With custom AI multiplier (0.0-1.0)
echo '{"operation": "function_points", "unadjusted_fp": 320, "complexity": "complex", "ai_multiplier": 0.4}' | python3 ${CLAUDE_SKILL_DIR}/scripts/estimate.py

AI levels: none (0%), low (20%), moderate (35%), high (50%), very_high (65%)

Output: Economic Feasibility Score (1-5) with cost summary table.

3c. Market Feasibility

For quick mode: Brief competitive check only, no deep market sizing.

Read references/market-analysis.md for the framework.

Analyze:

• Market size: TAM / SAM / SOM estimates
• Competitive landscape: Position vs. competitors found in Phase 2
• Differentiation: What makes this different? Is it defensible?
• Moat assessment: None / Shallow / Deep — with justification
• Timing: Too early / Right time / Too late

Output: Market Feasibility Score (1-5) with positioning summary.

3d. Operational Feasibility

Analyze:

• Team requirements: Roles, skills, hiring difficulty
• Process requirements: Development methodology, release cadence
• Support model: Customer support needs, SLA expectations
• Organizational readiness: Does the team have the skills? What gaps exist?

Output: Operational Feasibility Score (1-5) with team summary.

3e. Schedule Feasibility

Analyze:

• Phase breakdown: Discovery → MVP → Beta → Launch → Scale
• Milestone timeline: Calendar estimates for each phase
• Critical path: What must happen sequentially vs. in parallel
• Dependencies: External dependencies, blockers, long-lead items
• Schedule risks: What could cause delays

Output: Schedule Feasibility Score (1-5) with timeline table.

3f. Automation Feasibility

Read references/automation-analysis.md for the framework.

Analyze each operational function of the product for automation potential:

• Component automation audit: For every major component/function, classify as Fully Automatable / Partially Automatable / Requires Human
• Data pipeline automation: Can data collection, processing, and delivery run unattended? What breaks require human intervention?
• Quality assurance automation: Can correctness be validated programmatically (self-validating loops) or does it need human judgment?
• Customer lifecycle automation: Onboarding, billing, support — can the full customer journey be self-serve?
• Maintenance automation: Can ongoing upkeep (updates, monitoring, fixes) be handled by scheduled jobs + AI, or does it need manual attention?
• Human intervention points: List every remaining point where a human must intervene. For each, assess if AI can eventually replace it.
• Solo operator viability: Can one person run this product at scale with AI assistance, or does growth require proportional headcount?

Output: Automation Feasibility Score (1-5) with component automation table.

Scoring guide:

• 5: Fully automatable — runs unattended, self-heals, scales without headcount
• 4: Near-full automation — occasional human check-ins (weekly), AI handles rest
• 3: Partially automated — regular human tasks (daily), but core ops are automated
• 2: Heavily manual — most operations require human involvement
• 1: Not automatable — human-intensive at every step

Gate 2: Analysis Complete

Verify all dimensions are scored:

• Technical score assigned (1-5) with evidence
• Economic score assigned (1-5) with cost estimates
• Market score assigned (1-5) — skip detailed for quick mode
• Operational score assigned (1-5)
• Schedule score assigned (1-5) with timeline
• Automation score assigned (1-5) with component table
• Confidence level noted for each score (Low / Medium / High)

Do not proceed until all scores are assigned.

Phase 4: Risk Assessment

Skip this phase for --depth quick

Read references/risk-assessment.md for the framework.

1. Identify the top 5-10 risks across all TELOS dimensions
2. Score each risk: Likelihood (1-5) x Impact (1-5) = Risk Score
3. Classify: Critical (20-25) / High (12-19) / Medium (6-11) / Low (1-5)
4. For every Critical and High risk, propose a specific mitigation strategy
5. Check against the Red Flags checklist

Output: Risk matrix table sorted by risk score (highest first).

Phase 5: Synthesis and Recommendation

1. Calculate weighted overall score:

   • Technical: 20% weight
   • Economic: 20% weight
   • Market: 15% weight
   • Operational: 10% weight
   • Schedule: 10% weight
   • Automation: 25% weight

2. Map to recommendation:

   • Score >= 3.5: GO — proceed with development
   • Score 2.5-3.49: CONDITIONAL GO — proceed if conditions are met
   • Score < 2.5: NO-GO — do not proceed as planned

3. State:

   • Overall score and recommendation
   • Confidence level (Low / Medium / High)
   • Top 3 key assumptions that could change the recommendation
   • 3-5 concrete recommended next steps

Phase 6: Report Presentation and Discussion

Read references/report-template.md for the full output format.

Step 1: Save the full report

Generate the complete feasibility report and save to: feasibility-report-{product-name}-{YYYY-MM-DD}.md in the current working directory.

Step 2: Present inline summary with scorecard

Print the following formatted summary directly to the user:

---

## Feasibility Study: {Product Name}

### Verdict: {GO | NO-GO | CONDITIONAL GO}

| Dimension    | Score | Confidence | Key Finding                        |
|--------------|-------|------------|------------------------------------|
| Technical    | {X}/5 | {L/M/H}    | {one-line finding}                 |
| Economic     | {X}/5 | {L/M/H}    | {one-line finding}                 |
| Market       | {X}/5 | {L/M/H}    | {one-line finding}                 |
| Operational  | {X}/5 | {L/M/H}    | {one-line finding}                 |
| Schedule     | {X}/5 | {L/M/H}    | {one-line finding}                 |
| Automation   | {X}/5 | {L/M/H}    | {one-line finding}                 |
| **Overall**  | **{X.X}/5** |     |                                    |

### Key Numbers
- **Effort:** {X} person-months ({AI level}, {reduction}% AI reduction)
- **Calendar time:** {X} months (with {N} developer(s))
- **Cash cost:** ${X} (development labor + tools, excludes infra)
- **Annual operating cost:** ${range} (Year 1)
- **Payback period:** {range}

Note: Effort = total work. Calendar time = wall-clock months (depends on
team size). Cash cost = actual money spent (sweat equity = $0).

### Top 3 Risks
1. {risk} (Score: {X}) — {mitigation}
2. {risk} (Score: {X}) — {mitigation}
3. {risk} (Score: {X}) — {mitigation}

---

Step 3: Walk through key discussion points

After presenting the summary, walk the user through each key point interactively. Use AskUserQuestion to guide the discussion:

Ask: "Here are the key points I'd like to discuss. What would you like to dig into first?"

Options:

• Technical deep-dive — Architecture, stack choices, and the hardest engineering challenges
• Cost breakdown — Where the money goes, hidden costs, and how to optimize
• Competitive strategy — How to differentiate from existing players
• Risk mitigation — The highest-risk items and what to do about them
• Next steps — The recommended action plan to move forward
• Full report — Show the complete detailed report

Step 4: Discuss the selected topic

For whichever topic the user selects, expand on that section of the analysis with specifics, trade-offs, and actionable detail. After discussing, ask if they want to explore another topic or if they're done.

Step 5: Wrap up

When the user is done discussing, remind them:

• Full report saved to: feasibility-report-{product-name}-{date}.md
• Offer to open it: open {path}
• Offer to adjust any scores, re-run at a different depth, or analyze a different product

Important Rules

1. Evidence required: Every score needs concrete evidence. No "probably" or "likely" without data. If confidence is low, say so explicitly.
2. Hidden costs are mandatory: Never skip the hidden costs checklist in economic analysis. These are the costs that blow up budgets.
3. Honest confidence levels: If you lack data for a dimension, score confidence as Low and note what additional research would help.
4. No false precision: Use ranges, not exact numbers. "$150K-250K" is better than "$187,500" when the estimate is rough.
5. The report is the deliverable: Always produce the markdown report file. The inline summary is a preview, not a substitute.
6. Graceful degradation: If WebSearch is unavailable, proceed with provided info and note the limitation. Never block on tool availability.
7. Respect depth mode: Quick mode should feel fast. Don't over-analyze. Deep mode should feel thorough. Don't cut corners.