---
# === IDENTITY ===
id: business/startup-scaling/technology-scaling-assessment/2026
canonical_question: "When should I re-architect from MVP — technical debt assessment, database scaling, infrastructure migration?"
aliases:
  - "MVP re-architecture decision framework"
  - "Technical debt assessment for startups"
  - "When to migrate from monolith to microservices"
entity_type: execution_recipe
domain: business > startup-scaling > technology scaling assessment
region: global
jurisdiction: global
temporal_scope: 2025-2026

# === VERIFICATION ===
last_verified: 2026-03-12
confidence: 0.88
version: 1.0
first_published: 2026-03-12

# === TEMPORAL VALIDITY ===
temporal_validity:
  status: evolving
  last_breaking_change: "DORA metrics updated with DX Core 4 framework in 2025, adding developer experience and business impact dimensions alongside traditional deployment frequency and change failure rate"
  next_review: 2026-09-08
  change_sensitivity: high

# === CONSTRAINTS ===
constraints:
  - "Never re-architect and add features simultaneously — one major initiative at a time to avoid compounding risk"
  - "Database migrations must be backward-compatible — use expand/contract pattern to avoid downtime"
  - "Infrastructure costs typically increase 2-4x during migration before settling to 1.2-1.5x post-migration"
  - "Re-architecture takes 3-9 months for typical Series A startups — budget accordingly before fundraising"
  - "Minimum 80% test coverage on critical paths before starting migration — untested code migrates bugs, not features"

# === SKIP CONDITIONS ===
skip_this_unit_if:
  - condition: "User needs general scaling strategy, not technical assessment"
    use_instead: "business/startup-scaling/scaling-readiness-assessment/2026"
  - condition: "User has already decided to re-architect and needs execution plan"
    use_instead: "business/startup-scaling/process-scaling-framework/2026"
  - condition: "User is pre-revenue and still validating MVP"
    use_instead: "business/startup/mvp-scoping-framework/2026"

# === AGENT HINTS ===
inputs_needed:
  - key: current_stack
    question: "What is the current technology stack?"
    type: text
    options: ["Node.js monolith", "Python/Django monolith", "Ruby on Rails", "PHP/Laravel", "other"]
  - key: team_size
    question: "How many engineers are on the team?"
    type: choice
    options: ["1-3 (solo/tiny)", "4-8 (small)", "9-20 (growing)", "20+ (scaling)"]
  - key: current_scale
    question: "What is the current user/request scale?"
    type: choice
    options: ["< 1K DAU", "1K-10K DAU", "10K-100K DAU", "100K+ DAU"]
  - key: primary_pain
    question: "What is the primary scaling pain?"
    type: choice
    options: ["slow deployments", "database bottlenecks", "feature velocity declining", "reliability/uptime issues", "cost optimization"]

# === EXECUTION METADATA ===
execution:
  required_inputs:
    - name: "Codebase access and repository metrics"
      source: "engineering team / GitHub"
      format: "git repository with commit history, CI/CD pipeline data"
    - name: "Infrastructure monitoring data"
      source: "cloud provider dashboard / observability platform"
      format: "CPU/memory utilization, request latency, error rates (last 90 days)"
    - name: "Deployment and incident history"
      source: "CI/CD platform / incident tracker"
      format: "deployment frequency, change failure rate, MTTR logs"
  outputs:
    - name: "Technical debt scorecard"
      format: "structured document"
      description: "Scored assessment across 10 dimensions with prioritized remediation plan"
    - name: "Migration decision matrix"
      format: "spreadsheet/document"
      description: "Go/no-go decision with timeline, cost, and risk estimates for each migration option"
    - name: "Architecture evolution roadmap"
      format: "document with diagrams"
      description: "Phased plan from current state to target architecture with milestones and quality gates"
  tools_required:
    - name: "SonarQube / SonarCloud"
      purpose: "Static code analysis and technical debt measurement"
      tier: "free"
      cost: "$0 for open source, $150/mo for private repos"
      alternatives: ["CodeClimate", "Codacy", "ESLint/Pylint"]
    - name: "GitHub / GitLab analytics"
      purpose: "DORA metrics extraction (deployment frequency, lead time, MTTR, change failure rate)"
      tier: "free"
      cost: "$0 (built into platform)"
      alternatives: ["LinearB", "Jellyfish", "Sleuth"]
    - name: "Cloud monitoring (Datadog / Grafana / CloudWatch)"
      purpose: "Infrastructure utilization and bottleneck identification"
      tier: "paid"
      cost: "$23-50/host/mo"
      alternatives: ["New Relic (free tier)", "Prometheus + Grafana (self-hosted, $0)"]
  credentials_needed:
    - service: "Source code repository"
      type: "API token / SSH key"
      where_to_get: "GitHub Settings > Developer settings > Personal access tokens"
      free_tier_limits: "Unlimited for repository access"
    - service: "Cloud provider"
      type: "IAM credentials / service account"
      where_to_get: "AWS IAM / GCP Console / Azure AD"
      free_tier_limits: "Read-only access sufficient for assessment"
  estimated_duration: "2-5 days for full assessment, 1 day for quick scoring"
  estimated_cost: "$0-300 (tools) + 2-5 days engineering time"

# === DISTRIBUTION ===
canonical_source: "https://knowledgelib.io/business/startup-scaling/technology-scaling-assessment/2026"
suggested_citation: "Source: knowledgelib.io — AI Knowledge Library (verified 2026-03-12)"

# === RELATED UNITS ===
related_kos:
  depends_on:
    - id: "business/startup-scaling/scaling-readiness-assessment/2026"
      label: "Overall scaling readiness assessment"
    - id: "business/startup-scaling/product-market-fit-measurement/2026"
      label: "Product-market fit validation before investing in re-architecture"
  feeds_into:
    - id: "business/startup-scaling/process-scaling-framework/2026"
      label: "Process changes needed alongside technical scaling"
    - id: "business/startup-scaling/hiring-scale-up-playbook/2026"
      label: "Engineering hiring plan based on architecture decisions"
  related_to:
    - id: "business/startup-scaling/growth-model-design/2026"
      label: "Growth model that determines scaling requirements"
  alternative_to: []

# === SOURCES ===
sources:
  - id: src1
    title: "10-Point Technical Debt Assessment"
    author: Code Climate
    url: https://codeclimate.com/blog/10-point-technical-debt-assessment
    type: methodology
    published: 2025-01-15
    reliability: authoritative
  - id: src2
    title: "DORA Metrics: Complete Guide to Measuring DevOps Performance"
    author: DX
    url: https://getdx.com/blog/dora-metrics/
    type: methodology
    published: 2025-06-01
    reliability: authoritative
  - id: src3
    title: "From MVP to Scale-Up: The Technical Debt You Should Actually Keep"
    author: Pragmatic Coders
    url: https://www.pragmaticcoders.com/blog/from-mvp-to-scale-up-the-technical-debt-you-should-actually-keep
    type: industry_analysis
    published: 2025-03-20
    reliability: high
  - id: src4
    title: "Strangler Fig Pattern — Azure Architecture Center"
    author: Microsoft
    url: https://learn.microsoft.com/en-us/azure/architecture/patterns/strangler-fig
    type: official_docs
    published: 2025-01-01
    reliability: authoritative
  - id: src5
    title: "Technical Debt in 2025: Balancing Speed and Scalability"
    author: JetSoftPro
    url: https://jetsoftpro.com/blog/technical-debt-in-2025-how-to-keep-pace-without-breaking-your-product/
    type: industry_analysis
    published: 2025-04-10
    reliability: high
  - id: src6
    title: "How to Build Scalable Software Architecture for Startups"
    author: Decipher Zone
    url: https://www.decipherzone.com/blog-detail/scalable-software-architecture-for-startups
    type: guide
    published: 2025-08-01
    reliability: high
---

# Technology Scaling Assessment

## Purpose

This recipe produces a scored technical debt assessment, migration decision matrix, and phased architecture evolution roadmap — the three deliverables a startup CTO needs to decide when, what, and how to re-architect from MVP. The output answers the critical question: is the current architecture a growth bottleneck or still serviceable, and what is the cost/benefit of each migration path. [src1]

## Prerequisites
<!-- Agents: verify ALL prerequisites before executing. Missing prerequisites = failed execution. -->

- [ ] **Codebase access** — git repository with at least 6 months of commit history for trend analysis
- [ ] **CI/CD pipeline data** — deployment logs showing frequency, success/failure rates, build times
- [ ] **Infrastructure monitoring** — CPU/memory/disk utilization, request latency P50/P95/P99, error rates (last 90 days minimum)
- [ ] **Incident history** — postmortem records or incident tracker data (PagerDuty, OpsGenie, or equivalent)
- [ ] **Static analysis tool** — [SonarQube](https://www.sonarqube.org/) or [Code Climate](https://codeclimate.com/) configured on the repository

## Constraints
<!-- Hard rules. Agents: enforce throughout execution. Violating these = broken output or legal risk. -->

- Never re-architect and add features simultaneously — one major initiative at a time to avoid compounding risk [src3]
- Database migrations must be backward-compatible — use expand/contract pattern to avoid downtime [src4]
- Infrastructure costs typically increase 2-4x during migration before settling to 1.2-1.5x post-migration [src5]
- Re-architecture takes 3-9 months for typical Series A startups — budget accordingly before fundraising
- Minimum 80% test coverage on critical paths before starting migration — untested code migrates bugs, not features [src1]

## Tool Selection Decision

```
Which assessment depth?
├── Quick health check (1 day) — DORA metrics + code quality scan
│   └── PATH A: Automated Scan — SonarQube + GitHub analytics
├── Standard assessment (2-3 days) — Full 10-point scoring + bottleneck analysis
│   └── PATH B: Manual + Automated — Code review + monitoring analysis + DORA
├── Deep architecture review (4-5 days) — Full assessment + migration planning
│   └── PATH C: Architecture Audit — PATH B + load testing + migration prototyping
└── Pre-investment due diligence (5-7 days) — Investor-grade technical assessment
    └── PATH D: Full Due Diligence — PATH C + security audit + compliance review
```

| Path | Tools | Cost | Duration | Output Depth |
|------|-------|------|----------|-------------|
| A: Quick Scan | SonarQube, GitHub Analytics | $0 | 1 day | Scorecard only |
| B: Standard | SonarQube, Datadog/Grafana, manual review | $0-150 | 2-3 days | Scorecard + bottleneck map |
| C: Deep Review | All PATH B + k6/Locust, architecture diagrams | $0-300 | 4-5 days | Full assessment + migration plan |
| D: Due Diligence | All PATH C + security scanner, compliance checks | $200-500 | 5-7 days | Investor-grade report |

## Execution Flow

### Step 1: Extract DORA Metrics

**Duration**: 2-4 hours
**Tool**: GitHub/GitLab analytics, CI/CD logs

Collect the four DORA metrics from the last 90 days. These form the baseline for engineering health. [src2]

```bash
# GitHub: extract deployment frequency (last 90 days)
gh api repos/{owner}/{repo}/actions/runs --paginate \
  --jq '[.workflow_runs[] | select(.conclusion=="success" and .created_at > (now - 7776000 | todate))] | length'

# Calculate lead time for changes: time from first commit to production deploy
# Extract from CI/CD logs — median time from PR merge to deploy completion

# Change failure rate: deployments requiring hotfix or rollback / total deployments
# Count rollback commits or hotfix branches in last 90 days

# Mean time to recovery: median time from incident start to resolution
# Extract from incident tracker (PagerDuty, OpsGenie, or manual log)
```

**Scoring** (DORA benchmarks 2025):
| Metric | Elite | High | Medium | Low |
|--------|-------|------|--------|-----|
| Deployment frequency | On-demand (multiple/day) | Weekly-daily | Monthly-weekly | < monthly |
| Lead time for changes | < 1 hour | 1 day - 1 week | 1 week - 1 month | > 1 month |
| Change failure rate | < 5% | 5-10% | 10-15% | > 15% |
| Mean time to recovery | < 1 hour | < 1 day | 1 day - 1 week | > 1 week |

**Verify**: All four metrics have values from at least 30 data points
**If failed**: If deployment data is sparse, use git log analysis as proxy — `git log --oneline --after="90 days ago" | wc -l`

### Step 2: Run Static Code Analysis

**Duration**: 1-3 hours (setup + scan)
**Tool**: SonarQube / Code Climate

Run comprehensive static analysis to quantify technical debt. [src1]

```bash
# SonarQube (Docker quick-start for local scan)
docker run -d --name sonarqube -p 9000:9000 sonarqube:community

# After setup, run scanner on project
sonar-scanner \
  -Dsonar.projectKey=my-startup \
  -Dsonar.sources=./src \
  -Dsonar.host.url=http://localhost:9000 \
  -Dsonar.token=YOUR_TOKEN

# Key metrics to extract:
# - Technical debt ratio (minutes of remediation / total dev time)
# - Code coverage percentage
# - Cyclomatic complexity (avg per function)
# - Code duplication percentage
# - Security vulnerabilities count
# - Code smells count
```

**Score the 10-point assessment** (adapted from Code Climate):

| # | Dimension | What to Measure | Score 1-10 |
|---|-----------|----------------|------------|
| 1 | Code quality | SonarQube maintainability rating (A-E) | A=10, B=8, C=6, D=4, E=2 |
| 2 | Test coverage | Line coverage % | >80%=10, 60-80%=7, 40-60%=5, <40%=2 |
| 3 | Dependency freshness | % of deps on latest major version | >80%=10, 60-80%=7, <60%=4 |
| 4 | Build reliability | CI pass rate last 30 days | >98%=10, 95-98%=8, 90-95%=5, <90%=2 |
| 5 | Deploy velocity | Deployments per week | >5=10, 2-5=8, 1-2=5, <1=2 |
| 6 | Incident rate | Severity-1 incidents per month | 0=10, 1=7, 2-3=4, >3=2 |
| 7 | Database health | Slow query %, index coverage | All indexed=10, >90%=7, <90%=4 |
| 8 | API latency | P95 response time | <200ms=10, 200-500ms=7, 500ms-1s=4, >1s=2 |
| 9 | Security posture | Known vulnerabilities (CVEs) | 0 critical=10, 0 high=7, any high=3 |
| 10 | Documentation | README, API docs, architecture docs | Complete=10, partial=5, minimal=2 |

**Verify**: Total score calculated (max 100). Score < 50 = urgent re-architecture needed. 50-70 = planned remediation. > 70 = maintain and iterate.
**If failed**: If SonarQube setup fails, use `npx eslint . --format json` (JS) or `pylint --output-format=json` (Python) for basic quality metrics

### Step 3: Database Scaling Assessment

**Duration**: 2-4 hours
**Tool**: Database monitoring (pg_stat_statements, EXPLAIN ANALYZE), cloud metrics

Evaluate whether the database is the bottleneck — the most common scaling wall for MVPs. [src6]

```sql
-- PostgreSQL: identify slow queries (top 10 by total time)
SELECT query, calls, mean_exec_time, total_exec_time, rows
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;

-- Check table bloat and index usage
SELECT schemaname, tablename,
  pg_size_pretty(pg_total_relation_size(schemaname||'.'||tablename)) as total_size,
  n_live_tup, n_dead_tup,
  ROUND(100.0 * n_dead_tup / GREATEST(n_live_tup + n_dead_tup, 1), 1) as dead_pct
FROM pg_stat_user_tables
ORDER BY pg_total_relation_size(schemaname||'.'||tablename) DESC
LIMIT 20;

-- Check for missing indexes (sequential scans on large tables)
SELECT relname, seq_scan, idx_scan,
  ROUND(100.0 * seq_scan / GREATEST(seq_scan + idx_scan, 1), 1) as seq_pct,
  n_live_tup
FROM pg_stat_user_tables
WHERE n_live_tup > 10000
ORDER BY seq_scan DESC;
```

**Database scaling decision tree**:
```
Current pain point?
├── Slow queries (P95 > 500ms)
│   ├── Missing indexes → Add indexes (hours, no migration needed)
│   ├── N+1 queries → Fix application code (days)
│   └── Table too large → Partitioning or read replicas (weeks)
├── Connection limits hit
│   ├── No connection pooler → Add PgBouncer (hours)
│   └── Already pooling → Vertical scale or read replicas (days)
├── Write throughput bottleneck
│   ├── < 5K writes/sec → Optimize queries, batch writes (days)
│   └── > 5K writes/sec → Consider sharding or different DB (weeks-months)
└── Data model doesn't fit
    ├── Heavy JSON querying → Consider document DB for that slice (weeks)
    └── Graph relationships → Consider graph DB for that slice (weeks)
```

**Verify**: Top 10 slow queries identified, index coverage assessed, connection utilization measured
**If failed**: If pg_stat_statements not enabled, use `EXPLAIN ANALYZE` on known slow endpoints as fallback

### Step 4: Infrastructure Bottleneck Analysis

**Duration**: 2-4 hours
**Tool**: Cloud monitoring dashboard (AWS CloudWatch / GCP Monitoring / Datadog)

Map resource utilization patterns to identify infrastructure ceilings.

```bash
# Key metrics to collect (last 30 days):
# 1. CPU utilization: average, P95, max — across all instances
# 2. Memory utilization: average, P95, max
# 3. Disk I/O: read/write IOPS, latency
# 4. Network: bandwidth utilization, packet loss
# 5. Request latency: P50, P95, P99 by endpoint
# 6. Error rate: 4xx and 5xx rates by endpoint
# 7. Auto-scaling events: how often, how much

# AWS example — get CPU metrics for last 30 days
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --start-time $(date -d '30 days ago' -u +%Y-%m-%dT%H:%M:%S) \
  --end-time $(date -u +%Y-%m-%dT%H:%M:%S) \
  --period 3600 \
  --statistics Average Maximum p95 \
  --dimensions Name=InstanceId,Value=i-XXXXX
```

**Infrastructure scaling thresholds**:
| Resource | Green | Yellow | Red |
|----------|-------|--------|-----|
| CPU avg | < 40% | 40-70% | > 70% |
| Memory avg | < 60% | 60-80% | > 80% |
| Disk I/O | < 50% IOPS limit | 50-80% | > 80% |
| Request P95 | < 200ms | 200ms-1s | > 1s |
| Error rate | < 0.1% | 0.1-1% | > 1% |

**Verify**: All resource metrics collected for at least 30 days, peak utilization periods identified
**If failed**: If cloud monitoring is minimal, use `top`, `iostat`, `vmstat` during peak hours as manual collection

### Step 5: Build Migration Decision Matrix

**Duration**: 4-8 hours
**Tool**: Spreadsheet / document

Synthesize all findings into an actionable decision matrix. [src3] [src4]

```
MIGRATION OPTIONS ASSESSMENT:

Option 1: Optimize in place (no re-architecture)
├── Timeline: 2-4 weeks
├── Cost: $0-5K (engineering time only)
├── Risk: Low
├── Suitable when: Score > 60, no single dimension < 4, DB not bottlenecked
└── Expected improvement: 20-40% performance gain

Option 2: Strangler Fig migration (incremental)
├── Timeline: 3-6 months
├── Cost: $20K-80K (engineering time + infra)
├── Risk: Medium
├── Suitable when: Score 40-60, clear domain boundaries exist
└── Expected improvement: 50-70% performance gain, 2x deploy velocity

Option 3: Parallel rebuild (new system alongside old)
├── Timeline: 6-12 months
├── Cost: $80K-250K (dedicated team + infra)
├── Risk: High
├── Suitable when: Score < 40, fundamental architecture mismatch
└── Expected improvement: Complete architecture reset

Option 4: Platform migration (change cloud/DB/framework)
├── Timeline: 2-6 months
├── Cost: $15K-60K (engineering + potential vendor costs)
├── Risk: Medium-High
├── Suitable when: Vendor lock-in or cost is primary pain
└── Expected improvement: Variable — depends on target platform
```

**Decision criteria scoring**:

| Factor | Weight | Option 1 | Option 2 | Option 3 | Option 4 |
|--------|--------|----------|----------|----------|----------|
| Time to impact | 25% | High (fast) | Medium | Low (slow) | Medium |
| Engineering cost | 20% | Low | Medium | High | Medium |
| Risk of regression | 20% | Low | Medium | High | High |
| Long-term scalability | 20% | Low | High | High | Medium |
| Team disruption | 15% | Low | Medium | High | Medium |
| **Weighted score** | 100% | *Calculate* | *Calculate* | *Calculate* | *Calculate* |

**Verify**: All options scored, top recommendation selected with confidence level, timeline and budget estimated
**If failed**: If data is insufficient for confident scoring, flag gaps and recommend data collection period before deciding

### Step 6: Produce Architecture Evolution Roadmap

**Duration**: 4-8 hours
**Tool**: Document + diagramming tool (Mermaid, draw.io)

Create the phased roadmap with quality gates between phases.

```
PHASED ROADMAP (Strangler Fig example):

Phase 0: Foundation (Weeks 1-2)
├── Add comprehensive monitoring if missing
├── Increase test coverage to 80%+ on critical paths
├── Document current architecture (as-is diagram)
└── GATE: All baseline metrics established

Phase 1: Quick Wins (Weeks 3-6)
├── Add database indexes for top 10 slow queries
├── Implement connection pooling (PgBouncer)
├── Add CDN for static assets
├── Optimize N+1 queries in top 5 endpoints
└── GATE: P95 latency improved 30%+

Phase 2: Service Extraction (Weeks 7-16)
├── Extract highest-traffic domain into standalone service
├── Implement API gateway for routing
├── Add async processing for non-critical paths
├── Set up separate database for extracted service
└── GATE: Extracted service handling 100% of its traffic

Phase 3: Data Layer Evolution (Weeks 17-24)
├── Implement read replicas for query-heavy paths
├── Add caching layer (Redis) for hot data
├── Migrate to managed database if self-hosted
├── Implement proper backup and disaster recovery
└── GATE: Database can handle 10x current load

Phase 4: Operational Excellence (Ongoing)
├── Implement feature flags for safe rollouts
├── Add chaos engineering (start with GameDay exercises)
├── Establish SLOs and error budgets
├── Set up automated scaling policies
└── GATE: System meets defined SLOs for 30 consecutive days
```

**Output files**:
- `technical-debt-scorecard.md` — 10-point scored assessment with trend data
- `migration-decision-matrix.xlsx` — Weighted scoring of all options with recommendation
- `architecture-roadmap.md` — Phased plan with milestones, gates, and resource requirements
- `as-is-architecture.png` — Current state architecture diagram
- `to-be-architecture.png` — Target state architecture diagram

## Output Schema

```json
{
  "output_type": "technical_scaling_assessment",
  "format": "structured document bundle",
  "sections": [
    {"name": "dora_metrics", "type": "object", "description": "Four DORA metrics with scores and benchmarks", "required": true},
    {"name": "code_quality_score", "type": "number", "description": "Aggregate score 0-100 from 10-point assessment", "required": true},
    {"name": "database_assessment", "type": "object", "description": "Slow queries, index coverage, connection utilization, scaling ceiling", "required": true},
    {"name": "infrastructure_utilization", "type": "object", "description": "Resource utilization heatmap with bottleneck identification", "required": true},
    {"name": "migration_recommendation", "type": "string", "description": "Selected option (optimize/strangler/rebuild/migrate) with confidence", "required": true},
    {"name": "roadmap_phases", "type": "array", "description": "Ordered list of phases with gates, timeline, and resource needs", "required": true},
    {"name": "estimated_total_cost", "type": "string", "description": "Range estimate for full migration including engineering time", "required": true}
  ],
  "expected_deliverables": "3-5 documents + 2 diagrams",
  "sort_order": "priority descending by impact"
}
```

## Quality Benchmarks

| Quality Metric | Minimum Acceptable | Good | Excellent |
|---------------|-------------------|------|-----------|
| DORA metrics coverage | All 4 metrics measured | 90-day trend data | 12-month trend with seasonality |
| Code quality data points | SonarQube scan completed | 10-point assessment scored | Trend comparison with previous quarter |
| Database assessment depth | Top 10 slow queries identified | Index coverage + connection analysis | Load test results at 2x/5x/10x current |
| Roadmap specificity | Phase names and rough timeline | Specific milestones and gates | Resource allocation + budget per phase |
| Stakeholder readiness | CTO can present to team | CTO can present to board | Investor-grade technical due diligence |

**If below minimum**: Re-run data collection with broader time window, or engage external DevOps consultant for assessment validation.

## Error Handling

| Error | Likely Cause | Recovery Action |
|-------|-------------|----------------|
| pg_stat_statements not available | Extension not enabled | Run `CREATE EXTENSION pg_stat_statements;` and wait 24h for data |
| SonarQube scan fails on large codebase | Memory limit exceeded | Increase Docker memory to 4GB: `docker run -e SONAR_ES_BOOTSTRAP_CHECKS_DISABLE=true -m 4g` |
| Cloud metrics API returns empty data | Monitoring not configured or wrong region | Verify monitoring agent installed, check correct region/account |
| Git history too short for DORA metrics | New repo or squash-merged history | Use PR merge data instead of commits; accept lower confidence |
| Load test crashes production | Test run against production instead of staging | Always run load tests against staging; use feature flags for traffic shifting |

## Cost Breakdown

| Component | Free Tier | Paid Tier | At Scale |
|-----------|-----------|-----------|----------|
| Code analysis (SonarQube) | $0 (community) | $150/mo (cloud) | $400/mo (enterprise) |
| Monitoring (Datadog/Grafana) | $0 (Grafana OSS) | $23/host/mo | $50/host/mo |
| Load testing (k6/Locust) | $0 (self-hosted) | $0 (CLI) | $600/mo (cloud) |
| Engineering time (assessment) | 2 days | 3-5 days | 5-7 days |
| **Total for standard assessment** | **$0 + 2 eng-days** | **$150-300 + 3-5 eng-days** | **$500-1000 + 5-7 eng-days** |

## Anti-Patterns

### Wrong: Big Bang Rewrite
Stopping all feature development to rebuild the system from scratch. 60-80% of big bang rewrites fail or significantly overrun timeline and budget because the team underestimates hidden complexity in the existing system. [src3]

### Correct: Strangler Fig Approach
Incrementally replace components while the old system continues to serve traffic. Route new functionality through the new system, migrate existing functionality piece by piece, and decommission old components only after the new ones are proven. [src4]

### Wrong: Premature Microservices
Splitting a monolith into microservices before the team has the operational maturity to manage distributed systems. A team of 3-5 engineers managing 15 microservices spends more time on infrastructure than features. [src6]

### Correct: Modular Monolith First
Refactor the monolith into well-defined modules with clean boundaries. Extract to services only when a module has genuinely different scaling, deployment, or team ownership requirements.

### Wrong: Ignoring Database Until Crisis
Treating database optimization as a future problem until queries take 5+ seconds and the application becomes unusable during peak hours. [src5]

### Correct: Continuous Database Health Monitoring
Run weekly slow query reports, maintain index coverage above 95%, and set alerts for connection pool saturation. Address database issues incrementally rather than in emergency mode.

## When This Matters

Use this recipe when a startup CTO or technical founder needs to make an evidence-based decision about re-architecting from MVP — specifically when feature velocity is declining, reliability is suffering, or the team is spending more time on workarounds than new capabilities. The output provides the data and framework to decide whether to optimize, migrate incrementally, or rebuild, with realistic timelines and costs for each option.

## Related Units

- [Scaling Readiness Assessment](/business/startup-scaling/scaling-readiness-assessment/2026) — Overall organizational scaling readiness
- [Process Scaling Framework](/business/startup-scaling/process-scaling-framework/2026) — Process changes needed alongside technical scaling
- [Hiring Scale-Up Playbook](/business/startup-scaling/hiring-scale-up-playbook/2026) — Engineering team scaling to support architecture evolution
- [Growth Model Design](/business/startup-scaling/growth-model-design/2026) — Growth targets that determine scaling requirements
- [Product-Market Fit Measurement](/business/startup-scaling/product-market-fit-measurement/2026) — Validates PMF before investing in re-architecture