home / skills / eyadsibai / ltk / tech-stack-evaluation

This skill helps you compare tech stacks, evaluate frameworks, and make informed technology decisions across frontend, backend, and cloud options.

npx playbooks add skill eyadsibai/ltk --skill tech-stack-evaluation

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.7 KB
---
name: tech-stack-evaluation
description: Use when "evaluating technology", "choosing frameworks", "stack comparison", "technology decisions", or asking about "React vs Vue", "PostgreSQL vs MySQL", "AWS vs GCP", "build vs buy"
version: 1.0.0
---

<!-- Adapted from: claude-skills/engineering-team/tech-stack-evaluator -->

# Tech Stack Evaluation Guide

Framework for making technology decisions.

## When to Use

- Choosing between frameworks/libraries
- Evaluating cloud providers
- Making build vs buy decisions
- Planning technology migrations
- Standardizing tech stack

## Evaluation Framework

### Decision Matrix

| Factor | Weight | Option A | Option B | Option C |
|--------|--------|----------|----------|----------|
| Team Experience | 20% | Score | Score | Score |
| Community/Support | 15% | Score | Score | Score |
| Performance | 15% | Score | Score | Score |
| Scalability | 15% | Score | Score | Score |
| Cost (TCO) | 15% | Score | Score | Score |
| Integration | 10% | Score | Score | Score |
| Security | 10% | Score | Score | Score |

### Scoring Guide

| Score | Meaning |
|-------|---------|
| 5 | Excellent, best in class |
| 4 | Good, above average |
| 3 | Adequate, meets needs |
| 2 | Below average, concerns |
| 1 | Poor, significant issues |

## Common Comparisons

### Frontend Frameworks

| Factor | React | Vue | Angular |
|--------|-------|-----|---------|
| Learning Curve | Medium | Low | High |
| Ecosystem | Large | Medium | Large |
| Performance | Good | Good | Good |
| Enterprise | Yes | Growing | Yes |
| Job Market | Largest | Growing | Strong |

### Backend Languages

| Factor | Node.js | Python | Go | Java |
|--------|---------|--------|-----|------|
| Performance | Good | Medium | Excellent | Good |
| Ecosystem | Large | Large | Growing | Large |
| Learning | Easy | Easy | Medium | Hard |
| Concurrency | Event-loop | Async | Native | Threads |

### Databases

| Factor | PostgreSQL | MySQL | MongoDB | DynamoDB |
|--------|------------|-------|---------|----------|
| Type | Relational | Relational | Document | Key-Value |
| Scalability | Vertical | Vertical | Horizontal | Horizontal |
| Schema | Strict | Strict | Flexible | Flexible |
| Cost | Free | Free | Free/Paid | Usage |

### Cloud Providers

| Factor | AWS | GCP | Azure |
|--------|-----|-----|-------|
| Market Share | Largest | Growing | Second |
| Services | Most complete | Strong ML/Data | Enterprise |
| Pricing | Complex | Simpler | Complex |
| Free Tier | 12 months | Always free | 12 months |

## Evaluation Process

### Step 1: Define Requirements

```markdown
## Requirements
- Scale: [Expected users/requests]
- Performance: [Latency requirements]
- Budget: [Monthly/yearly budget]
- Team: [Current skills and size]
- Timeline: [Implementation deadline]
```

### Step 2: Identify Options

Research 3-5 viable options:

- Current market leaders
- Rising alternatives
- Team-familiar options

### Step 3: Proof of Concept

Build minimal POC for top 2-3 options:

- Core functionality
- Integration test
- Performance benchmark

### Step 4: Total Cost Analysis

| Cost Type | Option A | Option B |
|-----------|----------|----------|
| Licensing | $ | $ |
| Infrastructure | $ | $ |
| Development | $ | $ |
| Training | $ | $ |
| Maintenance | $ | $ |
| **Total (3 yr)** | $ | $ |

### Step 5: Risk Assessment

| Risk | Option A | Option B |
|------|----------|----------|
| Vendor lock-in | Low/Med/High | |
| Technology obsolescence | | |
| Skill availability | | |
| Security concerns | | |

## Build vs Buy

### Build When

- Core competitive advantage
- Unique requirements
- Long-term cost savings
- Team has expertise

### Buy When

- Commodity functionality
- Time to market critical
- Ongoing maintenance burden
- Industry standard exists

### Decision Tree

```
Is it core to your business?
├── Yes → Does expertise exist?
│   ├── Yes → Build
│   └── No → Buy (for now)
└── No → Buy or use open source
```

## Migration Planning

### Migration Phases

1. **Assessment** - Current state analysis
2. **Planning** - Target architecture
3. **Preparation** - Team training, tooling
4. **Migration** - Incremental rollout
5. **Validation** - Testing, monitoring
6. **Cutover** - Final switch
7. **Optimization** - Post-migration tuning

### Risk Mitigation

- Run parallel systems
- Feature flags for rollback
- Comprehensive testing
- Staged rollout
- Clear rollback plan

## Documentation Template

```markdown
# Technology Decision: [Name]

## Context
Why are we making this decision?

## Options Considered
1. [Option A] - Pros/Cons
2. [Option B] - Pros/Cons
3. [Option C] - Pros/Cons

## Decision
We chose [Option] because...

## Consequences
- Positive: [List]
- Negative: [List]

## Implementation Plan
- Phase 1: [Action]
- Phase 2: [Action]
```

Overview

This skill helps teams evaluate and choose technology stacks using a practical, score-based framework. It guides decisions across frameworks, cloud providers, databases, and build-vs-buy tradeoffs. The skill produces actionable comparisons, cost analyses, risk assessments, and migration plans to support informed, defensible choices.

How this skill works

The skill frames evaluations with a weighted decision matrix covering factors like team experience, community support, performance, scalability, cost, integration, and security. It scores candidate options, runs lightweight proof-of-concept guidance, and produces a total cost of ownership and risk assessment. It also offers build-vs-buy guidance and a migration checklist to operationalize the chosen path.

When to use it

  • Choosing between competing frameworks or libraries (e.g., React vs Vue)
  • Comparing cloud providers or managed services (e.g., AWS vs GCP)
  • Deciding whether to build custom software or purchase a product
  • Planning a technology migration or major platform upgrade
  • Standardizing a technology stack across teams or projects

Best practices

  • Define clear, measurable requirements (scale, latency, budget, timeline) before comparing options
  • Weight decision factors to reflect business priorities, not technical preferences
  • Prototype top options with small POCs to validate key assumptions
  • Quantify three-year total cost of ownership including training and maintenance
  • Assess vendor lock-in, skill availability, and security risks explicitly

Example use cases

  • Evaluate frontend frameworks for a new product: learning curve, ecosystem, hiring market
  • Compare PostgreSQL vs MySQL vs a NoSQL option for a data-heavy service
  • Decide between AWS and GCP for a machine-learning platform based on services and cost
  • Determine whether to build an internal analytics tool or buy a SaaS product
  • Plan a phased migration from a legacy monolith to microservices with rollback strategies

FAQ

How many options should I compare?

Research 3–5 viable options: market leaders, promising alternatives, and team-familiar choices.

What factors should be highest weighted?

Prioritize factors tied to business outcomes: team experience, scalability, performance, and total cost of ownership.

When should I choose buy over build?

Prefer buy for commodity functions, tight timelines, or when long-term maintenance is not a competitive differentiator.