tech-stack-selection

Tech Stack Selection

Overview

Tech Stack Selection is the process of choosing programming languages, frameworks, databases, and tools that will form the foundation of your system. Good choices enable productivity; poor choices create years of technical debt.

Core Principle: "Choose boring technology. Optimize for team productivity and long-term maintainability, not resume-driven development."

1. Selection Criteria Framework

Primary Criteria

2. The "Boring Technology" Rule

## Dan McKinley's "Choose Boring Technology"

**Rule**: You have ~3 "innovation tokens" per project. Spend them wisely.

### Example: E-commerce Startup

**Boring (Safe) Choices**:
- ✅ PostgreSQL (database) - Proven, reliable
- ✅ React (frontend) - Widely adopted, stable
- ✅ Node.js (backend) - Team knows it well

**Innovation Tokens Spent**:
- 🎫 Token 1: Kubernetes (new to team, but needed for scaling)
- 🎫 Token 2: GraphQL (better than REST for our use case)
- 🎫 Token 3: [Reserved for future needs]

**Avoided**:
- ❌ Rust backend (team doesn't know it)
- ❌ CockroachDB (PostgreSQL works fine)
- ❌ Svelte (React is good enough)

3. Technology Evaluation Matrix

## Example: Choosing a Frontend Framework

| Criteria | React | Vue | Svelte | Weight | Winner |
|----------|-------|-----|--------|--------|--------|
| **Team Expertise** | 5/5 (everyone knows) | 2/5 (1 person) | 1/5 (nobody) | 30% | React |
| **Ecosystem** | 5/5 (huge) | 4/5 (good) | 3/5 (growing) | 20% | React |
| **Performance** | 4/5 | 4/5 | 5/5 (fastest) | 15% | Svelte |
| **Hiring** | 5/5 (easy) | 4/5 | 2/5 (harder) | 15% | React |
| **Documentation** | 5/5 | 5/5 | 4/5 | 10% | React/Vue |
| **Bundle Size** | 3/5 | 4/5 | 5/5 (smallest) | 10% | Svelte |

**Weighted Score**:
- React: 4.5/5
- Vue: 3.6/5
- Svelte: 3.2/5

**Decision**: React (best fit for team and ecosystem)

4. Database Selection Guide

Relational (SQL)

**Choose PostgreSQL when**:
- Complex relationships between entities
- ACID transactions required
- Strong consistency needed
- Rich query capabilities (JOINs, CTEs)

**Examples**: E-commerce, Banking, ERP

**Choose MySQL when**:
- Read-heavy workloads
- Simpler data model
- Need master-slave replication

**Examples**: Content sites, Blogs

NoSQL

**Choose MongoDB when**:
- Flexible schema needed
- Document-oriented data
- Rapid prototyping

**Examples**: Content management, Catalogs

**Choose Redis when**:
- Caching layer
- Session storage
- Real-time features (pub/sub)

**Examples**: Cache, Leaderboards, Rate limiting

**Choose Cassandra when**:
- Massive write throughput
- Multi-datacenter replication
- Time-series data

**Examples**: IoT, Analytics, Logs

5. Language Selection

Backend Language Decision Tree

Do you need maximum performance?
├─ YES → Go, Rust
└─ NO → Continue

Do you have a large existing codebase?
├─ YES → Stick with current language
└─ NO → Continue

What's your team's expertise?
├─ JavaScript → Node.js/TypeScript
├─ Python → Python (Django/FastAPI)
├─ Java → Java/Kotlin (Spring Boot)
└─ None → TypeScript (easiest to hire)

Special requirements?
├─ ML/Data Science → Python
├─ Real-time/Gaming → Go, Rust
├─ Enterprise → Java
└─ Startups → TypeScript, Python

6. Framework Selection

Backend Framework

// Example: Node.js Framework Selection

// Express - Minimalist, flexible
app.get('/users', (req, res) => {
  // Manual validation, error handling
});

// Fastify - Performance-focused
fastify.get('/users', {
  schema: { /* validation */ }
}, async (req, reply) => {
  // Built-in validation, serialization
});

// NestJS - Enterprise, opinionated
@Controller('users')
export class UsersController {
  @Get()
  findAll(): Promise<User[]> {
    // Dependency injection, decorators
  }
}

// Decision: 
// - Express: Small projects, maximum flexibility
// - Fastify: Performance-critical APIs
// - NestJS: Large teams, enterprise apps

7. Cloud Provider Selection

## Cloud Provider Comparison

| Feature | AWS | GCP | Azure |
|---------|-----|-----|-------|
| **Market Leader** | ✅ Yes | ❌ No | ❌ No |
| **Best for ML** | ❌ No | ✅ Yes (TensorFlow) | ❌ No |
| **Best for .NET** | ❌ No | ❌ No | ✅ Yes |
| **Pricing** | Complex | Simpler | Complex |
| **Enterprise Support** | ✅ Excellent | ✅ Good | ✅ Excellent |
| **Kubernetes** | EKS | GKE (best) | AKS |

**Decision Factors**:
- Existing contracts/credits
- Team expertise
- Specific service needs (e.g., BigQuery on GCP)
- Geographic requirements

8. Proof of Concept (POC)

## POC Template for Technology Evaluation

### Objective
Evaluate [Technology X] for [Use Case]

### Success Criteria
- [ ] Can handle 10K requests/second
- [ ] Team can build basic CRUD in 1 day
- [ ] Integrates with existing auth system
- [ ] Deployment to staging works

### Timeline
- Day 1-2: Setup and basic implementation
- Day 3: Performance testing
- Day 4: Integration testing
- Day 5: Team review and decision

### Deliverables
- Working prototype
- Performance benchmarks
- Integration documentation
- Recommendation (Go/No-Go)

9. Technology Radar

## Company Technology Radar (ThoughtWorks Style)

### Adopt (Use for new projects)
- PostgreSQL
- TypeScript
- React
- Docker
- GitHub Actions

### Trial (Experiment in non-critical projects)
- Bun (JavaScript runtime)
- Turso (Edge database)
- Astro (Static site generator)

### Assess (Keep watching)
- Deno 2.0
- HTMX
- Rust for backend

### Hold (Don't use for new projects)
- jQuery
- AngularJS
- MongoDB (for transactional data)

10. Common Selection Mistakes

Anti-patterns

❌ **Resume-Driven Development**
"Let's use Rust because it's cool"
→ Team doesn't know Rust, project delayed 6 months

❌ **Hype-Driven Development**
"Everyone's using NoSQL, let's use MongoDB"
→ Needed ACID transactions, had to migrate to PostgreSQL

❌ **Not-Invented-Here Syndrome**
"Let's build our own auth system"
→ Security vulnerabilities, 6 months wasted

❌ **Analysis Paralysis**
"Let's evaluate 10 more frameworks"
→ Never ship, competitors win

✅ **Better Approach**
- Use what team knows
- Choose proven technologies
- Validate with small POC
- Ship and iterate

11. Technology Selection Checklist

• Requirements Clear: What problem are we solving?
• Team Expertise: Can team learn this in reasonable time?
• POC Completed: Have we validated it works for our use case?
• Ecosystem Evaluated: Are there libraries/tools we need?
• Performance Tested: Meets our performance requirements?
• Cost Analyzed: Total cost of ownership acceptable?
• Hiring Considered: Can we hire developers with this skill?
• Long-term Plan: What's the 3-5 year outlook?
• Exit Strategy: Can we migrate away if needed?
• Documented: Decision recorded in ADR?

12. Tech Stack Decision Template

# Tech Stack Decision: [Component Name]

## Context
We need to choose a [database/framework/language] for [use case].

## Requirements
- Performance: [specific metrics]
- Scale: [expected load]
- Team: [current expertise]
- Budget: [constraints]

## Options Evaluated

### Option 1: [Technology A]
**Pros**: [list]
**Cons**: [list]
**POC Results**: [link to POC]
**Score**: 7/10

### Option 2: [Technology B]
**Pros**: [list]
**Cons**: [list]
**POC Results**: [link to POC]
**Score**: 8/10

## Decision
We chose [Technology B] because [rationale].

## Mitigations
To address the cons:
- [Mitigation 1]
- [Mitigation 2]

## Next Steps
- [ ] Setup development environment
- [ ] Train team
- [ ] Update documentation

Related Skills

• 59-architecture-decision/adr-templates
• 59-architecture-decision/tradeoff-analysis
• 59-architecture-decision/architecture-review