# Maintenance and Technical Debt Planning

## Purpose

Turn vague maintenance needs into a practical, sequenced plan that improves delivery speed, reliability, and future change safety over time.

## When to use

- The codebase has accumulated risky or slowing debt
- A team needs to prioritize cleanup against feature work
- Repeated friction suggests structural maintenance investment is overdue
- You need to explain why maintenance work matters in product terms

## Inputs to gather

- Known pain points, repeated failures, and slow areas in delivery
- Architectural hotspots, obsolete patterns, and fragile dependencies
- Team constraints, roadmap pressure, and acceptable disruption
- Evidence of cost: incidents, churn, slowed feature work, or support burden

## How to work

- Focus on debt that materially changes future delivery, reliability, or risk.
- Group issues into themes rather than a flat list of annoyances.
- Prioritize by impact, urgency, and dependency relationships.
- Prefer incremental sequences that can ship safely between feature work.
- Translate maintenance value into outcomes the team can defend.

## Output expectations

- Prioritized maintenance plan or backlog proposal
- Clear rationale for what should happen now versus later
- Sequencing guidance and expected payoff

## Quality checklist

- Recommendations are tied to real delivery or reliability pain.
- Prioritization is explicit and defensible.
- The plan is incremental enough to execute.
- Work is framed in terms of reduced risk or increased velocity, not vague cleanliness.

## Handoff notes

- Note what evidence would strengthen or change the prioritization.
- Pair with roadmap and opportunity prioritization when balancing debt against new initiatives.