tech-stack-evaluation
Tech Stack Evaluation Skill
Purpose
Produce objective, criteria-driven technology comparisons that teams can trust and defend to stakeholders.
Evaluation Framework
Step 1 — Define the Context First
Before scoring anything, state:
- Use case: what specifically needs to be built
- Team size & skills: what the team already knows
- Scale target: expected load, data volume, users
- Timeline: prototype vs. long-term production system
- Constraints: budget, compliance, existing infrastructure
A technology that scores well in one context can be the wrong choice in another.
Step 2 — Evaluation Criteria (score each 1–5)
Always evaluate every candidate against these 8 criteria:
| Criteria | Weight | Description |
|---|---|---|
| Performance | High | Throughput, latency, resource efficiency at target scale |
| Developer Experience | High | Learning curve, tooling, debugging, documentation quality |
| Ecosystem Maturity | High | Community size, library availability, long-term viability |
| Operational Complexity | Medium | Deployment, monitoring, maintenance burden |
| Scalability | Medium | Horizontal scaling, sharding, clustering capabilities |
| Security | Medium | Known vulnerabilities, security model, compliance support |
| Cost | Medium | Licensing, infrastructure cost, operational overhead |
| Team Fit | High | Existing expertise, hiring market, training cost |
Add domain-specific criteria if needed (e.g., mobile: battery usage; database: ACID compliance).
Step 3 — Comparison Table
| Criteria | Weight | [Option A] | [Option B] | [Option C] |
|---|---|---|---|---|
| Performance | High | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ |
| Dev Experience | High | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐ |
| Ecosystem | High | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| Ops Complexity | Medium | ⭐⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐ |
| Scalability | Medium | ⭐⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Security | Medium | ⭐⭐⭐⭐ | ⭐⭐⭐ | ⭐⭐⭐⭐ |
| Cost | Medium | ⭐⭐⭐ | ⭐⭐⭐⭐⭐ | ⭐⭐⭐ |
| Team Fit | High | ⭐⭐⭐⭐⭐ | ⭐⭐ | ⭐⭐⭐ |
| Overall | Strong | Moderate | Weak |
Step 4 — Per-Option Summary
For each technology:
[Option Name]
- ✅ Best for: [specific use cases where it excels]
- ❌ Avoid when: [specific conditions where it fails]
- ⚠️ Watch out for: [hidden costs, common pitfalls]
- 📦 Key dependencies/lock-in: [what you commit to by choosing this]
Step 5 — Recommendation
State clearly:
Recommended: [Option X] for this context because [2–3 specific reasons tied to the project constraints].
If it's genuinely close, say so and explain the deciding factor.
Do not recommend a technology without stating what would change the recommendation.
Anti-Patterns to Avoid
- Resume-driven development: don't recommend what's trendy, recommend what fits
- Ignoring team fit: a 20% better tool the team doesn't know will underperform
- Benchmark theater: cherry-picked benchmarks without context are misleading
- Switching cost blindness: always account for migration effort from current stack
- Vendor hype: apply extra skepticism to any tool in its first 2 years
Red Flags in Any Technology
- No clear company or foundation backing it long-term
- Documentation is sparse or community is declining
- Security advisories are frequent with slow patches
- Forced vendor lock-in with no migration path
- Repository
- achreftlili/deep-dev-skills
- Commit
181fcbc
- Last updated
- First committed
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.