| 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"] |
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
- 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.
- Identify candidates — List 2-4 realistic options. Exclude clearly wrong choices early.
- Define weighted evaluation criteria — Select 6-8 criteria from the master list below. Assign weights based on the user's priorities (total = 100%).
- Score each candidate — Rate 1-5 on each criterion with one-line justification per score.
- Assess ecosystem health — Evaluate GitHub activity, npm/PyPI adoption, community strength, corporate backing, and trajectory (growing, stable, declining).
- 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.
- Analyze migration path — If migrating, estimate effort, risks, timeline, and recommend phased approach (strangler fig pattern).
- 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 designcicd-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.
