tech-stack-eval

name	tech-stack-eval
description	When the user needs to choose between technologies, frameworks, or tools — or says "which framework should I use", "compare X vs Y", "should we migrate from X to Y", "what database should I use", "calculate TCO".
related	["architecture-design","cicd-setup"]
reads	["startup-context"]
origin	startup

Tech Stack Evaluation

When to Use

• Comparing frontend/backend frameworks or libraries for new projects
• Evaluating cloud providers (AWS vs Azure vs GCP) for specific workloads
• Planning technology migrations with risk and effort assessment
• Calculating TCO including hidden costs; making build vs. buy decisions
• Assessing open-source library viability and ecosystem health

Do NOT use when: the decision is trivial (use team preference), the technology is already mandated, or this is an emergency production issue.

Context Required

From startup-context: product type, team skills, tech stack, stage, scale, budget. Also ask:

• What problem are you solving? (push back on solution-first thinking)
• Non-negotiable requirements (performance, compliance, team familiarity)
• Team experience with each option and timeline pressure (tight deadlines favor familiar tools)
• Growth expectations that affect scalability requirements

Workflow

1. Clarify the decision — What exactly is being decided and what are the real requirements? Push back if the user picks tech before defining the problem.
2. Identify candidates — List 2-4 realistic options. Exclude clearly wrong choices early.
3. Define weighted evaluation criteria — Select 6-8 criteria from the master list below. Assign weights based on the user's priorities (total = 100%).
4. Score each candidate — Rate 1-5 on each criterion with one-line justification per score.
5. Assess ecosystem health — Evaluate GitHub activity, npm/PyPI adoption, community strength, corporate backing, and trajectory (growing, stable, declining).
6. Calculate TCO — Project 5-year total cost including compute, storage, bandwidth, licensing, engineering time (setup + ongoing), and operational overhead. Engineering time is usually the largest cost for startups.
7. Analyze migration path — If migrating, estimate effort, risks, timeline, and recommend phased approach (strangler fig pattern).
8. Deliver recommendation — Clear winner with rationale and confidence level. No "it depends" without a follow-up question to resolve the ambiguity.

Output Format

# Tech Stack Evaluation: [Decision Title]

## Decision Context — what we are choosing and why it matters
## Candidates — table: technology, version, license, one-liner
## Evaluation Criteria — table: criterion, weight, why it matters
## Scoring Matrix — table: criterion (weight), scores per option, weighted total
## Ecosystem Health — table: GitHub stars, weekly downloads, last release, open issues, major users
## TCO Estimate — table: cost category by option over 12 months or 5 years
## Security & Compliance — vulnerability history, compliance readiness (SOC 2, GDPR)
## Recommendation — clear winner, rationale, confidence level, caveats
## Migration Path (if applicable) — phased plan with timeline and rollback strategy

Frameworks & Best Practices

Master Evaluation Criteria

Select 6-8 and assign weights (total = 100%):

• Performance — throughput, latency, resource efficiency for the specific workload
• Developer Experience — tooling, debugging, documentation quality, error messages
• Learning Curve / Team Familiarity — time to productivity for the current team
• Ecosystem & Libraries — packages, integrations, third-party support
• Maintenance & Longevity — release cadence, corporate backing, bus factor
• Hiring Pool — developer availability in your market and salary band
• Scalability — handle 10-100x growth without a rewrite
• Cost / Vendor Lock-in — TCO and switching cost if you need to move later
• Security & Compliance — vulnerability track record, compliance tooling readiness

Ecosystem Health Scoring

Level	Criteria
Thriving	Regular releases (< 3 months), growing adoption, multiple corporate sponsors, active community
Stable	Regular releases (< 6 months), steady adoption, established community, no decline signs
At Risk	Infrequent releases (> 12 months), declining downloads, key maintainers leaving, few contributors

TCO Calculation Framework

Project over 12 months minimum (5 years for infrastructure decisions): compute, storage, bandwidth, licensing, engineering time (setup + ongoing maintenance x loaded cost), operational overhead (monitoring, on-call), and hidden costs (training, migration tooling, dual-running).

Engineering time is usually the largest cost for startups. A technology saving $200/month on hosting but costing 40 extra engineering hours to operate is a net loss.

Migration Risk Assessment

Risk Level	Criteria
Low	Additive change, no data migration, can run in parallel, < 2 weeks
Medium	Requires data migration or API changes, 2-8 weeks, can be phased
High	Core system replacement, > 8 weeks, requires downtime or big-bang cutover

Use the strangler fig pattern: route new traffic to the new system, migrate old incrementally. Always maintain rollback capability. Set a concrete cut-off date -- half-migrated systems are the worst outcome.

Confidence Levels

Level	Score	Interpretation
High	80-100%	Clear winner, strong data, wide margin
Medium	50-79%	Trade-offs present, recommendation holds but with caveats
Low	< 50%	Close call, limited data, suggest a proof-of-concept before committing

Common Decision Anti-Patterns

• Resume-Driven Development — choosing tech for resumes, not fit
• Hype Cycle Trap — adopting at peak hype before stability is proven
• Premature Optimization — distributed systems when a single Postgres handles the load
• Sunk Cost Fallacy — refusing to migrate because of prior investment
• Ignoring Team Skills / Solution-First Thinking — picking tech nobody knows, or selecting technology before defining the problem

Related Skills

• architecture-design — chain when the tech stack decision feeds into a broader system design
• cicd-setup — chain to configure CI/CD for the chosen technology

Examples

Example prompt: "Compare React vs Vue for a SaaS dashboard. Priorities: developer productivity (40%), ecosystem (30%), performance (30%)."

Good output snippet:

## Scoring Matrix
| Criterion (weight)       | React | Vue  |
|--------------------------|-------|------|
| Developer Productivity (40%) | 4/5   | 4/5  |
| Ecosystem (30%)          | 5/5   | 4/5  |
| Performance (30%)        | 4/5   | 5/5  |
| **Weighted Total**       | **4.3** | **4.3** |

Confidence: Medium (55%). Scores are nearly identical. Recommendation: React,
but only because your team has 2 years of React experience (not captured in
the matrix). If the team were greenfield, Vue's developer experience gives it
a slight edge. This is close enough to warrant team preference as the tiebreaker.

Example prompt: "We're on Heroku at $2,400/mo. Should we migrate to AWS?"

Good output snippet:

## TCO Estimate (12 months)
| Category             | Heroku    | AWS               |
|----------------------|-----------|-------------------|
| Compute              | $1,200/mo | $480/mo (ECS)     |
| Database             | $800/mo   | $350/mo (RDS)     |
| Add-ons              | $400/mo   | $120/mo           |
| Engineering (setup)  | $0        | $12,000 one-time  |
| Engineering (ongoing)| 2 hrs/mo  | 8 hrs/mo          |
| **Annual Total**     | **$28,800** | **$18,000**     |

Break-even at month 14. At Series A with a team of 6, wait until Heroku hits
$4,000/mo — engineering hours are better spent on product right now.