Technical signals:
→ Core architectural assumption proven wrong — the approach won't work
→ Performance targets demonstrably unachievable with current design
→ Technical debt from fast iteration has accumulated past the point of return
→ Key dependency no longer available or maintained
→ Security vulnerability discovered that invalidates the approach

Business signals:
→ Market assumptions underlying the project have changed
→ Competitor shipped equivalent — first-mover advantage gone
→ User research shows the problem isn't the one we thought we were solving
→ Revenue assumptions don't hold — unit economics don't work

Team signals:
→ Team morale collapsed around the project
→ Key expertise left the team
→ Estimates have been wrong by > 3x for three consecutive milestones
→ Team has lost faith in the project's viability

The hardest part:
→ Any one of these might be survivable
→ Multiple together usually aren't
→ The question is whether to fight through or redirect

// Structured assessment before any kill/continue decision
interface ProjectHealthCheck {
  technicalViability: {
    coreAssumptionsValid: boolean
    performanceTargetsAchievable: boolean
    estimatedCompletionWeeks: number
    confidenceInEstimate: 'high' | 'medium' | 'low'
  }
  businessViability: {
    marketOpportunityStillExists: boolean
    unitEconomicsWork: boolean
    competitiveAdvantage: string
    urgencyOfCompletion: 'high' | 'medium' | 'low'
  }
  teamViability: {
    teamConfidence: number  // 1-5 scale
    hasRequiredExpertise: boolean
    morale: 'high' | 'medium' | 'low'
  }
}

function assessProjectHealth(check: ProjectHealthCheck): ProjectDecision {
  const technicalScore = [
    check.technicalViability.coreAssumptionsValid,
    check.technicalViability.performanceTargetsAchievable,
    check.technicalViability.confidenceInEstimate !== 'low',
  ].filter(Boolean).length

  const businessScore = [
    check.businessViability.marketOpportunityStillExists,
    check.businessViability.unitEconomicsWork,
    check.businessViability.urgencyOfCompletion !== 'low',
  ].filter(Boolean).length

  const teamScore = [
    check.teamViability.teamConfidence > 3,
    check.teamViability.hasRequiredExpertise,
    check.teamViability.morale !== 'low',
  ].filter(Boolean).length

  const totalScore = technicalScore + businessScore + teamScore  // Max 9

  if (totalScore >= 7) return 'continue'
  if (totalScore >= 5) return 'pivot'  // Significant changes needed
  if (totalScore >= 3) return 'reassess-in-30-days'
  return 'kill'  // Three fundamental issues across all dimensions
}

The argument that kills bad projects:

Step 1: Separate sunk cost from future investment
"We've spent 6 months. That $800k is gone whether we continue or stop.
The decision is: should we spend the NEXT 6 months (another $800k) on this?"

Step 2: Estimate cost to completion with confidence intervals
"Our best estimate to working MVP: 3-6 more months.
High confidence we'd need 6-9 months.
We've been wrong by 3x before — could be 12 months."

Step 3: Estimate the cost of NOT stopping
"If we spend another 6-9 months and it still doesn't work,
we've spent $1.6M and lost 12 months to market."

Step 4: Compare to alternatives
"If we redirect these 3 engineers to [other opportunity],
here's what we could ship and what that's worth."

Step 5: Propose the decision
"My recommendation: stop this project and redirect to X.
I could be wrong. Here's what would change my mind: [specific condition]."

The goal isn't to prove you're right — it's to put a clear,
reasoned recommendation on the table so the right person can decide.

// Sometimes the right answer is neither kill nor continue — it's pivot
// Preserve the work that's valuable, abandon the parts that aren't

interface PivotOption {
  keepFromCurrentProject: string[]
  abandonFromCurrentProject: string[]
  newScope: string
  reducedTimeline: string
  reducedCost: string
}

const examplePivot: PivotOption = {
  keepFromCurrentProject: [
    'Database schema and migration work (3 months of effort)',
    'API design patterns and documentation',
    'Authentication and authorization layer',
    'CI/CD pipeline and deployment infrastructure',
  ],
  abandonFromCurrentProject: [
    'Custom ML pipeline (performance targets unachievable)',
    'Real-time sync feature (too complex for current stage)',
  ],
  newScope: 'Build MVP without custom ML — use third-party inference instead',
  reducedTimeline: '6 weeks instead of 6 months',
  reducedCost: '$120k instead of remaining $800k estimate',
}

// The pivot preserves the foundation work while abandoning the risky
// assumptions. Often the most politically achievable option.

# When killing a project, extract the value before the code goes dark
# Future projects will ask "why didn't this work?" — document the answer

# Create a project retrospective document:
cat > retrospective.md << 'EOF'
# Project: [Name]
## Duration: [Start] → [End]
## Investment: $[Amount]

## What We Built
[Brief description of what was implemented]

## Why We Stopped
[Honest explanation — technical/business/team reasons]

## What We Learned
- [Learning 1: specific technical or business insight]
- [Learning 2]

## What We'd Do Differently
- [Different approach 1]
- [Different approach 2]

## Assets Worth Preserving
- [Code/patterns/infrastructure worth carrying forward]

## Assets to Archive (Not Delete)
- Git repository: [link]
- Design documents: [link]
- Database schema: [link]

## Fix 5: Team Recovery After a Canceled Project

## Project Kill Decision Checklist

- ✅ Sunk cost separated from future investment — only future cost matters in the decision
- ✅ Business case documented: cost to complete vs cost of alternatives
- ✅ Pivot option explored: can we keep the value and abandon the risk?
- ✅ Clear recommendation made by the most informed engineer — not just escalated as "unclear"
- ✅ Knowledge preservation: retrospective document and repo archived with context
- ✅ Assets worth saving explicitly identified and incorporated into other work
- ✅ Team recovery plan: acknowledge, celebrate wins, assign to meaningful work quickly

## Conclusion

Killing a project is an act of organizational health, not failure. The failure would be spending another six months on something that can't succeed because stopping feels painful. The engineering case for stopping requires separating sunk cost from future investment, making a clear recommendation with a confidence interval, and proposing the pivot or kill with specific conditions that would change the conclusion. The teams that develop this muscle — honest assessment, clear recommendation, graceful exit — recover from failed projects faster and build better institutional knowledge for the next one.