Maintenance vs Development
Not all work is equal. Some tasks keep the system running as it is; others change what the system is. Understanding the distinction is essential because each type of work follows a different process, pricing model, and expectation of effort.
Maintenance
Maintenance preserves the existing system.
It keeps current behaviour intact, stable, and safe. No new thinking is required—only restoration to a known state.
Maintenance includes:
- Fixing bugs where functionality has regressed from what was originally delivered
- Restoring broken features to their intended behaviour
- Applying dependency updates, security patches, and other routine technical upkeep
- Adjusting configuration, content, or copy without altering logic or workflow
- Minor tweaks that do not introduce new decisions, exceptions, or user journeys
If the system behaves the same before and after the work, it is maintenance.
Development
Development changes how the system behaves.
It introduces something new—capabilities, workflows, decisions, or user experiences that did not exist before.
Development includes:
- New features, new screens, new workflows, and new logic
- Enhancing existing functionality beyond its original scope
- Integrations with other systems or services
- Changes that alter user journeys or add exception handling
- Work requiring engineering judgement, UX consideration, or architectural choices
If the system can do something after the work that it could not do before, it is development.
The Practical Divider
The intent behind the work determines the category:
Maintenance preserves. Development transforms.
Most confusion arises from small requests that appear trivial but have hidden consequences—often framed as “can you just…”.
To classify correctly, ask:
Does this request:
- Require new decisions?
- Change user behaviour or outcomes?
- Introduce new exceptions or conditions?
- Require scoping or architectural consideration?
If yes to any of the above, it is development, regardless of size.
Why This Distinction Matters
Different expectations apply:
| Aspect | Maintenance | Development |
|---|---|---|
| Purpose | Preserve existing behaviour | Introduce or change behaviour |
| Process | Quick triage and fix | Discovery, design, and build |
| Risk | Low | Variable—can be high |
| Pricing | Typically retainer | Project or scoped estimate |
| Ownership | Delivery team | Product & Technology Lead involved where required |
Misclassification leads to disappointment: maintenance budgets evaporate, delivery dates slip, and assumptions collide.
This distinction ensures work is routed correctly, costed appropriately, and delivered with the care it deserves.
Summary
If the work restores something that already exists, it’s maintenance.
If the work changes how the system behaves, it’s development.
When in doubt, classify by impact, not size.