Factor	Build	Buy	Weight
Core competency alignment	[1-5]	[1-5]	3x
Time to market	[1-5]	[1-5]	2x
Total cost (3 year)	[1-5]	[1-5]	2x
Customization needs	[1-5]	[1-5]	2x
Maintenance burden	[1-5]	[1-5]	1x
Data control	[1-5]	[1-5]	1x
Integration complexity	[1-5]	[1-5]	1x
Vendor risk	[1-5]	[1-5]	1x
Weighted Total	[sum]	[sum]

Decision: BUILD / BUY / HYBRID


### Decision Rules

| Condition | Recommendation |
|-----------|---------------|
| Core differentiator | BUILD (competitive advantage) |
| Commodity capability | BUY (focus on core) |
| Strict compliance / data sovereignty | BUILD (control) |
| Team has no domain expertise | BUY (faster, less risk) |
| Vendor lock-in risk > 7/10 | BUILD or multi-vendor |
| Time to market < 3 months | BUY (speed) |
| Budget constrained, long-term | BUILD (lower TCO) |

### Build vs Buy Anti-Patterns

| Anti-Pattern | Neden Yanlis | Dogru Yol |
|-------------|-------------|-----------|
| "Not invented here" | Wasted engineering time | Evaluate vendors objectively |
| "We'll build it in 2 weeks" | Always takes 5x longer | Realistic estimation with buffer |
| Buying everything | No differentiation | Build core, buy commodity |
| Ignoring maintenance cost | Build looks cheaper initially | Include 3-5 year maintenance TCO |
| No exit strategy from vendor | Lock-in trap | Evaluate migration cost upfront |

## Tech Debt Quantification & Prioritization

### Tech Debt Classification

| Type | Description | Impact | Example |
|------|-------------|--------|---------|
| **Code debt** | Poor code quality | Developer velocity | No types, huge functions, no tests |
| **Architecture debt** | Wrong architectural decisions | Scalability | Monolith that should be microservice |
| **Test debt** | Insufficient test coverage | Reliability | No integration tests, flaky tests |
| **Dependency debt** | Outdated dependencies | Security | 3 major versions behind, CVEs |
| **Documentation debt** | Missing/outdated docs | Onboarding | No API docs, stale README |
| **Infrastructure debt** | Manual processes, legacy infra | Reliability | No CI/CD, manual deployments |
| **Design debt** | UX inconsistencies | User experience | 5 different button styles |

### Tech Debt Scorecard

```markdown
## Tech Debt Assessment: [Project Name]

| Area | Score (1-10) | Trend | Priority |
|------|-------------|-------|----------|
| Code quality | [X] | [up/down/flat] | [H/M/L] |
| Test coverage | [X%] | [up/down/flat] | [H/M/L] |
| Dependency freshness | [X] | [up/down/flat] | [H/M/L] |
| Build/deploy time | [X min] | [up/down/flat] | [H/M/L] |
| Documentation | [X] | [up/down/flat] | [H/M/L] |
| Security posture | [X] | [up/down/flat] | [H/M/L] |

### Cost of Delay
[If we don't address debt area X, what happens in 6 months?]

### Investment Request
| Initiative | Effort | Impact | ROI Period |
|-----------|--------|--------|------------|
| [debt 1] | [weeks] | [description] | [months] |
| [debt 2] | [weeks] | [description] | [months] |

Prioritization Formula

Priority Score = (Impact * Urgency * Spread) / Effort

Impact (1-5):    How much does it slow the team?
Urgency (1-5):   How quickly will it get worse?
Spread (1-5):    How many areas does it affect?
Effort (1-5):    How hard is it to fix? (inverse: 1=hard, 5=easy)

Tech Debt Budget Rule

RULE: 20% of sprint capacity reserved for tech debt reduction

Sprint capacity: 10 story points
├── 8 points: Feature work
└── 2 points: Tech debt reduction (ZORUNLU, negotiable degil)

Team Scaling Strategies

Hiring Framework

## Hiring Plan: [Quarter/Year]

### Current State
| Role | Headcount | Capacity | Gap |
|------|-----------|----------|-----|
| Backend | [X] | [Y features/quarter] | [shortfall] |
| Frontend | [X] | [Y features/quarter] | [shortfall] |
| DevOps | [X] | [Y deploys/week] | [shortfall] |
| QA | [X] | [Y tests/sprint] | [shortfall] |

### Ratios
- Engineer : Manager = 6-8 : 1
- Senior : Mid : Junior = 2 : 3 : 1
- Backend : Frontend = project-dependent
- Engineer : QA = 4-6 : 1

### Onboarding Milestones
| Day | Milestone |
|-----|-----------|
| 1 | Dev environment running, first commit |
| 7 | First PR merged |
| 14 | First feature shipped to staging |
| 30 | Independent task completion |
| 60 | Contributing to architecture discussions |
| 90 | Fully productive, mentoring others |

Team Topology Patterns

Pattern	When to Use	Size
Stream-aligned	Product features	5-8 people
Platform	Internal tooling, infrastructure	3-5 people
Enabling	Coach other teams, remove blockers	2-3 people
Complicated subsystem	Deep expertise (ML, security)	2-4 people

Architecture Decision Records (ADR)

ADR Template

# ADR-[number]: [decision title]

## Status
[Proposed | Accepted | Deprecated | Superseded by ADR-XXX]

## Context
[What is the issue? What forces are at play?]
[Include constraints, requirements, team capabilities]

## Decision
[What is the change that we're proposing and/or doing?]

## Alternatives Considered
### Option A: [name]
- Pros: [list]
- Cons: [list]

### Option B: [name]
- Pros: [list]
- Cons: [list]

## Consequences
### Positive
- [benefit 1]
- [benefit 2]

### Negative
- [tradeoff 1]
- [tradeoff 2]

### Risks
- [risk 1]: [mitigation]
- [risk 2]: [mitigation]

## Decision Date
[YYYY-MM-DD]

## Decision Makers
[names/roles]

ADR Index

## Architecture Decision Log

| # | Decision | Status | Date | Impact |
|---|---------|--------|------|--------|
| 001 | Use PostgreSQL over MongoDB | Accepted | 2025-01-15 | High |
| 002 | Adopt microservices for billing | Accepted | 2025-02-01 | High |
| 003 | Use React over Vue | Accepted | 2025-02-15 | Medium |
| 004 | Monolith-first for MVP | Deprecated | 2025-03-01 | High |

Technology Evaluation Framework

RICE Scoring

## Technology Evaluation: [Technology Name]

### RICE Score

| Factor | Score | Weight | Weighted |
|--------|-------|--------|----------|
| **Reach** (how many people/teams affected) | [1-10] | 1x | [X] |
| **Impact** (how much improvement per person) | [1-3: minimal/medium/massive] | 2x | [X] |
| **Confidence** (how sure are we) | [50-100%] | 1x | [X] |
| **Effort** (person-months) | [X] | divisor | [X] |

**RICE Score = (Reach * Impact * Confidence) / Effort = [score]**

Weighted Scoring Matrix

## Vendor/Technology Comparison

| Criteria | Weight | Option A | Option B | Option C |
|----------|--------|----------|----------|----------|
| Performance | 20% | [1-5] | [1-5] | [1-5] |
| Community/support | 15% | [1-5] | [1-5] | [1-5] |
| Learning curve | 15% | [1-5] | [1-5] | [1-5] |
| Cost | 15% | [1-5] | [1-5] | [1-5] |
| Scalability | 10% | [1-5] | [1-5] | [1-5] |
| Security | 10% | [1-5] | [1-5] | [1-5] |
| Integration | 10% | [1-5] | [1-5] | [1-5] |
| Maturity | 5% | [1-5] | [1-5] | [1-5] |
| **Weighted Total** | | [sum] | [sum] | [sum] |

### Recommendation: [Option X]
### Reasoning: [1-2 sentences]

Technology Evaluation Anti-Patterns

Anti-Pattern	Risk	Dogru Yol
Resume-driven development	Wrong tool for the job	Evaluate against actual needs
Hype-driven adoption	Immature ecosystem	Wait for version 2.0+
Single vendor evaluation	No comparison baseline	Always evaluate 3+ options
Ignoring exit cost	Future lock-in	Calculate migration cost
No POC/prototype	Unknown unknowns	Build spike before committing

Budget Planning & TCO Analysis

TCO Template (3-Year)

## Total Cost of Ownership: [System/Technology]

### Year 1 (Setup + Operations)
| Category | Cost |
|----------|------|
| Licenses/subscriptions | $[X] |
| Infrastructure (cloud/hardware) | $[X] |
| Implementation/migration | $[X] |
| Training | $[X] |
| Integration development | $[X] |
| **Year 1 Total** | **$[X]** |

### Year 2-3 (Ongoing)
| Category | Annual Cost |
|----------|------------|
| Licenses/subscriptions (+ annual increase) | $[X] |
| Infrastructure | $[X] |
| Maintenance engineering (FTE fraction) | $[X] |
| Support contracts | $[X] |
| Upgrades/patches | $[X] |
| **Annual Ongoing** | **$[X]** |

### 3-Year TCO: $[Year 1 + Year 2 + Year 3]

### Hidden Costs (often missed)
- Context switching overhead
- On-call/incident response time
- Documentation maintenance
- Vendor management overhead
- Compliance/audit costs

Vendor Management

Vendor Assessment Checklist

Vendor Risk Matrix

Risk	Likelihood	Impact	Mitigation
Vendor acquired/shutdown	Low	Critical	Data export procedure, backup vendor
Price increase > 30%	Medium	High	Multi-year contract, alternative evaluation
SLA breach	Medium	High	Credits, contractual remedies
Data breach at vendor	Low	Critical	Encryption, contractual liability
Feature deprecation	Medium	Medium	API abstraction layer

Engineering Metrics

DORA Metrics

Metric	Elite	High	Medium	Low
Deployment Frequency	On-demand (multiple/day)	Daily-weekly	Weekly-monthly	Monthly-6monthly
Lead Time for Changes	< 1 hour	1 day - 1 week	1 week - 1 month	1 - 6 months
Change Failure Rate	0-15%	16-30%	16-30%	16-30%
Mean Time to Recovery	< 1 hour	< 1 day	1 day - 1 week	> 1 week

SPACE Framework

Dimension	Metrics	How to Measure
Satisfaction	Developer satisfaction survey	Quarterly survey (1-5 scale)
Performance	Code review turnaround, incident resolution	Tooling metrics
Activity	PRs merged, deploys, commits	Git/CI data (NOT for evaluation)
Communication	Knowledge sharing, documentation	Survey + doc metrics
Efficiency	Dev environment setup time, build time	Measure and track

Engineering Health Dashboard

## Engineering Health: [Quarter]

### DORA Metrics
| Metric | Target | Actual | Status |
|--------|--------|--------|--------|
| Deploy frequency | Daily | [X/week] | [on/off track] |
| Lead time | < 1 day | [X hours] | [on/off track] |
| Change failure rate | < 15% | [X%] | [on/off track] |
| MTTR | < 1 hour | [X min] | [on/off track] |

### Team Health
| Area | Score (1-10) | Trend |
|------|-------------|-------|
| Developer satisfaction | [X] | [up/down/flat] |
| On-call burden | [X] | [up/down/flat] |
| Tech debt sentiment | [X] | [up/down/flat] |
| Tooling satisfaction | [X] | [up/down/flat] |

### Actionable Insights
1. [Insight + recommended action]
2. [Insight + recommended action]

Board/Investor Technical Reporting

Quarterly Tech Report Template

## Technology Report: Q[X] [Year]

### Executive Summary
[2-3 sentences: key wins, risks, requests]

### Key Metrics
| Metric | Q-1 | Q0 | Target | Trend |
|--------|-----|-----|--------|-------|
| Uptime | [X%] | [X%] | 99.9% | [arrow] |
| Page load time | [Xs] | [Xs] | < 2s | [arrow] |
| Active users | [X] | [X] | [target] | [arrow] |
| Deploy frequency | [X/mo] | [X/mo] | Daily | [arrow] |

### Achievements
1. [Milestone/launch/improvement]
2. [Milestone/launch/improvement]

### Risks & Challenges
| Risk | Severity | Mitigation | Status |
|------|----------|-----------|--------|
| [risk] | [H/M/L] | [plan] | [active/mitigated] |

### Budget
| Category | Budget | Actual | Variance |
|----------|--------|--------|----------|
| Infrastructure | $[X] | $[X] | [+/-X%] |
| Licenses | $[X] | $[X] | [+/-X%] |
| Headcount | $[X] | $[X] | [+/-X%] |

### Next Quarter Focus
1. [Priority 1]
2. [Priority 2]
3. [Priority 3]

### Resource Request
[If applicable: what do we need and why]

Board Communication Anti-Patterns

Anti-Pattern	Neden Yanlis	Dogru Yol
Too much jargon	Board members aren't engineers	Translate to business impact
Only good news	Erodes trust	Honest + solution-oriented
No metrics	Unverifiable	Data-driven with trends
Feature list only	No business context	Connect features to revenue/growth
Asking for budget without ROI	Unlikely approval	Show expected return

cto-advisor

CTO Advisor

Build vs Buy Decision Framework

Decision Matrix