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 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.
1---2name: tech-stack-eval3description: 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".4---5
6# Tech Stack Evaluation
7
8## When to Use
9
10- Comparing frontend/backend frameworks or libraries for new projects
11- Evaluating cloud providers (AWS vs Azure vs GCP) for specific workloads
12- Planning technology migrations with risk and effort assessment
13- Calculating TCO including hidden costs; making build vs. buy decisions
14- Assessing open-source library viability and ecosystem health
15
16Do NOT use when: the decision is trivial (use team preference), the technology is already mandated, or this is an emergency production issue.
17
18## Context Required
19
20From `startup-context`: product type, team skills, tech stack, stage, scale, budget. Also ask:
21- What problem are you solving? (push back on solution-first thinking)
22- Non-negotiable requirements (performance, compliance, team familiarity)
23- Team experience with each option and timeline pressure (tight deadlines favor familiar tools)
24- Growth expectations that affect scalability requirements
25
26## Workflow
27
281. **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.
292. **Identify candidates** — List 2-4 realistic options. Exclude clearly wrong choices early.
303. **Define weighted evaluation criteria** — Select 6-8 criteria from the master list below. Assign weights based on the user's priorities (total = 100%).
314. **Score each candidate** — Rate 1-5 on each criterion with one-line justification per score.
325. **Assess ecosystem health** — Evaluate GitHub activity, npm/PyPI adoption, community strength, corporate backing, and trajectory (growing, stable, declining).
336. **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.
347. **Analyze migration path** — If migrating, estimate effort, risks, timeline, and recommend phased approach (strangler fig pattern).
358. **Deliver recommendation** — Clear winner with rationale and confidence level. No "it depends" without a follow-up question to resolve the ambiguity.
36
37## Output Format
38
39```markdown
40# Tech Stack Evaluation: [Decision Title]
41
42## Decision Context — what we are choosing and why it matters
43## Candidates — table: technology, version, license, one-liner
44## Evaluation Criteria — table: criterion, weight, why it matters
45## Scoring Matrix — table: criterion (weight), scores per option, weighted total
46## Ecosystem Health — table: GitHub stars, weekly downloads, last release, open issues, major users
47## TCO Estimate — table: cost category by option over 12 months or 5 years
48## Security & Compliance — vulnerability history, compliance readiness (SOC 2, GDPR)
49## Recommendation — clear winner, rationale, confidence level, caveats
50## Migration Path (if applicable) — phased plan with timeline and rollback strategy
51```
52
53## Frameworks & Best Practices
54
55### Master Evaluation Criteria
56
57Select 6-8 and assign weights (total = 100%):
58
59- **Performance** — throughput, latency, resource efficiency for the specific workload
60- **Developer Experience** — tooling, debugging, documentation quality, error messages
61- **Learning Curve / Team Familiarity** — time to productivity for the current team
62- **Ecosystem & Libraries** — packages, integrations, third-party support
63- **Maintenance & Longevity** — release cadence, corporate backing, bus factor
64- **Hiring Pool** — developer availability in your market and salary band
65- **Scalability** — handle 10-100x growth without a rewrite
66- **Cost / Vendor Lock-in** — TCO and switching cost if you need to move later
67- **Security & Compliance** — vulnerability track record, compliance tooling readiness
68
69### Ecosystem Health Scoring
70
71| Level | Criteria |
72|-------|----------|
73| **Thriving** | Regular releases (< 3 months), growing adoption, multiple corporate sponsors, active community |
74| **Stable** | Regular releases (< 6 months), steady adoption, established community, no decline signs |
75| **At Risk** | Infrequent releases (> 12 months), declining downloads, key maintainers leaving, few contributors |
76
77### TCO Calculation Framework
78
79Project 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).
80
81**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.
82
83### Migration Risk Assessment
84
85| Risk Level | Criteria |
86|------------|----------|
87| **Low** | Additive change, no data migration, can run in parallel, < 2 weeks |
88| **Medium** | Requires data migration or API changes, 2-8 weeks, can be phased |
89| **High** | Core system replacement, > 8 weeks, requires downtime or big-bang cutover |
90
91Use 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.
92
93### Confidence Levels
94
95| Level | Score | Interpretation |
96|-------|-------|----------------|
97| **High** | 80-100% | Clear winner, strong data, wide margin |
98| **Medium** | 50-79% | Trade-offs present, recommendation holds but with caveats |
99| **Low** | < 50% | Close call, limited data, suggest a proof-of-concept before committing |
100
101### Common Decision Anti-Patterns
102
103- **Resume-Driven Development** — choosing tech for resumes, not fit
104- **Hype Cycle Trap** — adopting at peak hype before stability is proven
105- **Premature Optimization** — distributed systems when a single Postgres handles the load
106- **Sunk Cost Fallacy** — refusing to migrate because of prior investment
107- **Ignoring Team Skills / Solution-First Thinking** — picking tech nobody knows, or selecting technology before defining the problem
108
109## Related Skills
110
111- `architecture-design` — chain when the tech stack decision feeds into a broader system design
112- `cicd-setup` — chain to configure CI/CD for the chosen technology
113
114## Examples
115
116**Example prompt:** "Compare React vs Vue for a SaaS dashboard. Priorities: developer productivity (40%), ecosystem (30%), performance (30%)."
117
118**Good output snippet:**
119```
120## Scoring Matrix
121| Criterion (weight) | React | Vue |
122|--------------------------|-------|------|
123| Developer Productivity (40%) | 4/5 | 4/5 |
124| Ecosystem (30%) | 5/5 | 4/5 |
125| Performance (30%) | 4/5 | 5/5 |
126| **Weighted Total** | **4.3** | **4.3** |
127
128Confidence: Medium (55%). Scores are nearly identical. Recommendation: React,
129but only because your team has 2 years of React experience (not captured in
130the matrix). If the team were greenfield, Vue's developer experience gives it
131a slight edge. This is close enough to warrant team preference as the tiebreaker.
132```
133
134**Example prompt:** "We're on Heroku at $2,400/mo. Should we migrate to AWS?"
135
136**Good output snippet:**
137```
138## TCO Estimate (12 months)
139| Category | Heroku | AWS |
140|----------------------|-----------|-------------------|
141| Compute | $1,200/mo | $480/mo (ECS) |
142| Database | $800/mo | $350/mo (RDS) |
143| Add-ons | $400/mo | $120/mo |
144| Engineering (setup) | $0 | $12,000 one-time |
145| Engineering (ongoing)| 2 hrs/mo | 8 hrs/mo |
146| **Annual Total** | **$28,800** | **$18,000** |
147
148Break-even at month 14. At Series A with a team of 6, wait until Heroku hits
149$4,000/mo — engineering hours are better spent on product right now.
150```