Maintain
Maintenance effort per year
The yearly person-hours to keep the suite alive: repairs, heal reviews, platform upkeep and new cases.
- Unit
- hours per year
- Where you enter it
- Computed; shown on the Maintain tab.
What it means
Cases to repair multiplied by repair time, plus cases healed multiplied by review time, plus platform upkeep, plus new cases multiplied by the time to build one. It is an output, per vendor, and it recurs every year.
It is the phase that separates a tool that is cheap to buy from a tool that is cheap to own.
Why it matters to the cost
Over five years maintenance usually exceeds the initial build for script-based and homegrown tooling, and it is the cost that a proof of concept never shows because nothing has changed yet. It is where self-healing, object repositories and resilient locators earn their licence — or fail to.
Typical values
For a 300-case suite: roughly 30–60 hours a year for AI-native tools; 150–250 for script-based tools; 350 or more for a homegrown framework.
Typical values describe a category of tool — AI-native, codeless, script-based, homegrown, manual — never a named product. Why we do not price named products.
Where it appears in the model
Maintain — continuously
- cases to repair
- Total test cases × Test breakage rate
- cases healed
- Total test cases × Self-healed cases per year
- Maintenance effort per year
- cases to repair × Repair time per case + cases healed × Review one heal + Platform upkeep per year + New cases added per year × Build a new case
- Maintenance cost per year
- Maintenance effort per year × Effective hourly rate + Token cost
Every name is a link to its definition. See the whole model.
Try it with your numbers
Maintenance effort per year is a row in the calculator. Change it and every total on the page moves with it — free, in your browser, nothing to install.
See how maintenance effort per year impacts the calculation of test automation costsLast reviewed 2026-09-15. All terms.