Selenium is free. Your Selenium suite isn't.
The licence costs nothing. The cost simply moves — into writing scripts, into repairing them every release, into the specialist salary required to do both, and into the grid you run them on. Here's where the money actually goes, what the published benchmarks say, and the point at which a suite starts costing more than it returns.
Maintenance is 20–40% of your build cost. Every year.
Published benchmarks put annual maintenance at 15–30% of initial build cost, with 20–40% typical for UI suites. Maintenance running above 40% annually is widely treated as a warning sign that the suite is failing rather than functioning.
Put concretely: a suite that cost $60,000 to build does not cost $60,000. It costs $60,000, plus $12,000–$24,000 every year, indefinitely, and that recurring line does not stop when releases slow down. It's the cost of standing still.
of initial build cost, spent annually on maintenance for UI suites.
of QA time typically consumed maintaining existing tests rather than writing new ones.
of automation initiatives abandoned within two years, usually when maintenance becomes unsustainable.
Six costs, and only one of them is the licence.
1. The framework you build first
Before a single test exists, someone builds the harness: runner configuration, CI wiring, page objects, waits, retry logic, reporting. Typically $15,000–$30,000 of engineering time, and it's the least visible line in any business case because it produces no tests.
2. The engineers who write the tests
Scripted suites need people who can write code. QA automation engineers average about $118,000 a year in the US and carry a $20,000–$40,000 premium over manual testers at the same experience level. Loaded first-year cost including benefits, recruiting, tooling and ramp runs roughly 1.4–2.4× base salary.
3. Repairing selectors after every release
This is the recurring killer. Tests bind to element identifiers; the application changes; the tests break. Not because the feature is wrong — because the selector moved. The faster you ship, the more repair work you generate, which means automation quietly penalises the velocity it was bought to enable.
4. Triaging flake
A failing test costs engineering time whether or not the failure is real. Once a meaningful share of runs are red for environmental reasons, teams start ignoring failures — at which point the suite has stopped functioning as a safety net while still costing full price.
5. Framework upkeep
Separate from test maintenance: the harness itself needs care. Dependency updates, driver versions, reporter changes, flaky-wait tuning. Budget roughly 20–30% of a senior engineer's time, permanently.
6. The grid
Parallel execution across browsers and devices needs infrastructure, whether self-hosted or cloud. $8,000–$20,000 a year once parallel runs are real, and it scales with how often you run.
How a healthy suite becomes an abandoned one.
It follows a recognisable sequence, and it rarely starts with a bad decision:
Months 1–6. The build goes well. Coverage climbs, the team is proud of it, leadership sees green dashboards. ROI at this point is negative — that's normal front-loading, not failure, though teams that measure here often panic.
Months 6–12. The application changes. Tests break for reasons unrelated to product defects. Maintenance was budgeted optimistically or not at all, so repair competes with new coverage — and new coverage usually loses.
Months 12–18. A fifth to a third of tests are failing. The team spends more time fixing tests than writing them. Red builds become normal, so failures get waved through. The suite still runs; it just isn't trusted.
Months 18–24. Someone asks why we're paying for this. The honest answer is that nobody can point to a defect it caught recently. The initiative is quietly deprioritised, and the investment is written off. More than 70% of automation programs reach this point within two years.
The cruel part is that abandoning looks like a saving. You stop paying maintenance, so the spreadsheet improves. What actually happened is that you wrote off the build, went back to manual regression at a fraction of the old cadence, and started shipping with less coverage than before.
Three levers, and better discipline isn't one of them.
Every team that failed had a plan to maintain the suite. The failure isn't discipline — it's that maintenance scales with release velocity, so the problem grows exactly as the business succeeds. What changes the economics is structural:
Stop binding to selectors
If a test describes intent rather than pointing at an element ID, the interface can be rebuilt underneath it without generating repair work. That removes the single largest recurring cost line.
Move authoring off the specialist
When only automation engineers can write tests, coverage is gated by the scarcest, most expensive person in the org. Business-readable tests move that work to whoever understands the process.
Make healing prove itself
Self-healing that swaps in the nearest matching element can pass a test against the wrong thing. A repair validated against the step's intent fails loudly instead — which is what keeps a green run meaningful.
Straight answers.
How much does Selenium maintenance actually cost?
Published benchmarks put annual maintenance at 15–30% of initial build cost, with 20–40% typical for UI suites, and above 40% treated as a warning sign. On a $60,000 build that's roughly $12,000–$24,000 every year, indefinitely.
Why is Selenium free but expensive?
The licence is free; the cost moves into writing and maintaining scripts. Tests bind to selectors that change whenever the application changes, so every release creates repair work — and scripted suites need automation engineers, who average about $118,000 a year and carry a $20,000–$40,000 premium over manual testers.
What percentage of QA time goes to maintenance?
Around 40% is the commonly reported figure — capacity that automation was supposed to free up in the first place.
Should we abandon Selenium?
Not necessarily. If your suite is engineering-owned, your team has strong framework skills, and maintenance is genuinely under control, an open framework is portable, free, and fully in your hands. The economics turn when maintenance starts consuming the capacity it was meant to release — the ROI calculator shows where that line falls for your suite.
How do we reduce maintenance cost?
Three structural levers: stop binding tests to selectors, move authoring off the scarce specialist, and make self-healing validate repairs against test intent rather than swapping in the nearest match. Better discipline alone doesn't work, because maintenance scales with release velocity.
Send us ten of your manual test cases. Untouched.
No reformatting, no rewriting into anyone's syntax. That's the whole evaluation.