achreftlili/architect/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