Most boards see one line for engineering and assume it buys roadmap. In practice, a share of that line pays for keeping existing applications running, and the software maintenance cost engineering budget owners carry is rarely measured. When the roadmap slips and the answer is to hire, the real question is how much capacity you already pay for but cannot deploy.
This guide gives CTOs and CFOs a way to answer it. It defines the maintenance tax, shows a step-by-step calculation with a worked example, and explains how to decide which part of the burden to eliminate, keep, or externalize.
TABLE OF CONTENTS
Where Does Software Maintenance Cost Engineering Budget Go?
A meaningful share goes to what we call the maintenance tax: engineering capacity consumed by reactive or non-differentiating application support, plus avoidable friction from the current estate and operating model. Finance still sees it as engineering spend, Product sees missed commitments, and the CTO experiences a capacity problem.
The three views describe the same hours. A developer budgeted to product engineering may spend Monday on an incident, Tuesday on support tickets, Wednesday rebuilding a failed integration, and only two days on the roadmap. The maintenance tax connects those views into one number.
Maintenance Tax Versus Essential Run Cost
Not all run work is a tax. Routine security patching, compliance work, and a floor of application operation are necessary no matter who performs them. Calling every run activity a tax inflates the business case and loses the CFO's trust, so the model separates essential run cost from the avoidable remainder.
Why There Is No Universal Benchmark
You will see claims that maintenance consumes a fixed share of every budget. Treat them with caution, because published figures often mix infrastructure operations, software maintenance, and all run spending under one label. No standard accounting definition matches the maintenance tax, so the defensible approach is to measure your own components and compare them with adjacent evidence.
Atlassian's 2025 survey of 3,500 developers and managers offers a friction envelope. Developers reported spending 16% of their time coding, 50% said they lose ten or more hours a week to non-coding tasks, and 90% said they lose six or more, mostly to organizational inefficiencies. On a 40-hour week, that is 15% to 25% of capacity.
That figure is broader than maintenance, so do not label it all as maintenance tax. Its value is as a plausibility check: if your measured tax lands in a similar range, the result is not exotic, even if Finance never saw it on a ledger.
What Does the Maintenance Tax Include Beyond Tickets?
The maintenance tax covers visible support work plus a hidden layer that ticket counts miss. It includes support tickets, incidents and on-call burden, context-switching cost, technical debt friction, rework due to fragility, manual maintenance overhead, and time spent hunting for documentation or owners. Each component needs its own data source and its own rule against double counting.
| Component | Calculation | Anti-double-counting rule |
| Application-support tickets | Tickets x median engineering touch time x loaded rate | Count engineering effort, not elapsed ticket time |
| Incident and on-call burden | Incidents x engineer-hours involved | Remove hours already logged on a ticket |
| Context-switching cost | Qualifying interruptions x measured recovery time x engineers interrupted | Measure recovery locally, do not assume it |
| Technical debt friction | Incremental hours from workarounds, legacy constraints, unsupported dependencies | Count added friction, not all work on old code |
| Rework due to fragility | Regression fixes + reopened defects + failed-change recovery + retest and redeploy | Exclude planned product refinement |
| Manual maintenance overhead | Repetitive release, data correction, and environment work that could be automated or transferred | Keep one-time governance out of the recurring tax |
| Knowledge-search friction | Time finding docs, service owners, APIs, or environment details | Skip if already captured in ticket touch time |
Ticket Volume Versus Context-Switching Cost
A production ticket may need 45 minutes of code investigation. The real capacity loss also includes triage, finding documentation, reproducing the problem, talking to operations, switching away from planned work, returning to it, testing, and deploying the fix. Atlassian's finding that information discovery and context switching are among developers' leading time-wasters supports measuring this cost separately from recorded ticket effort.
Technical Debt and Rework Due to Fragility
Do not assume every hour of technical debt is waste, or that debt explains all slowness. A 2024 industrial case study by Paudel and colleagues examined six software components and found that technical debt accounted for between 5% and 41% of the variance in issue lead time, depending on the component. The authors point to change size, complexity, team involvement, and ownership as other factors.
The practical lesson is to measure debt-driven rework directly, application by application, instead of applying one blanket percentage.
Shadow Activities: On-Call and Knowledge Hunting
Incident response, post-incident reviews, repetitive manual tasks, and the search for the one engineer who knows an integration all draw on the same people. They rarely appear in a ticket system. Sample them through a short developer diary or survey rather than asking engineers to estimate a year of history from memory.
How Do You Calculate Your Maintenance Tax Step by Step?
Define the labor pool, collect four to six weeks of operational data, sample developer time for what systems cannot see, and then convert hours into a percentage of capacity and a dollar equivalent. A short measurement sprint is more defensible than asking engineers what share of their year went to debt.
Step 1: Define the Labor Pool and Capacity
Choose the roles in scope: engineers, QA, DevOps or SRE, support staff, delivery leads who join incident resolution, and engineering management. Then use the same pool in the numerator and the denominator. Do not put developer hours on top and the whole technology organization's spend below.
Step 2: Pull Operational Data for Four to Six Weeks
From your service management tool, capture ticket volume, severity, application, reopen rate, escalations, and engineering touch time. From incident and on-call tools, capture engineer-hours and repeat incidents. From source control and CI/CD, capture hotfixes, regressions, failed deployments, and reopened work.
Step 3: Sample Developer Time for the Invisible Costs
Run a two-week lightweight sampling exercise to estimate context-switching cost, documentation search, and legacy-workaround effort. Keep it short enough that engineers actually complete it. Where possible, connect code-quality telemetry with work-management data, as the 2024 industrial study did.
Step 4: Convert Hours to Percent and Dollars
Maintenance tax percent equals maintenance-tax hours divided by total engineering capacity hours. Maintenance tax dollars equal maintenance-tax hours multiplied by the fully loaded hourly engineering cost. If the labor pool is fairly uniform, you can approximate dollars as the tax percent multiplied by the relevant engineering spend.
Use actual payroll and finance data for loaded cost. As a sanity check, U.S. Bureau of Labor Statistics data for June 2026 shows wages were 70.0% of employer compensation costs for private industry workers and benefits 30.0%. It covers all occupations, not engineers, but it shows why salary alone understates the cost base.
Worked Example (Illustrative, Not a Benchmark)
Assume 40 engineers and adjacent technical staff, $7.2 million in annual fully loaded spend, and 2,080 gross hours per person. Total modeled capacity is 83,200 hours.
| Observed burden | Illustrative annual input | Tax hours |
| Support tickets | 1,800 tickets x 2.2 engineering hours | 3,960 |
| Production incidents | 160 incidents x 3.5 hours x 2.5 engineers | 1,400 |
| Context-switching cost | 40 engineers x 3 interruptions a week x 0.5 recovery hour x 48 weeks | 2,880 |
| Technical debt friction | Measured incremental legacy-workaround time | 5,800 |
| Rework due to fragility | Regressions, reopened defects, hotfix, retest, redeploy | 4,600 |
| Manual release and support overhead | Repetitive non-roadmap operational work | 2,400 |
| Total maintenance tax | 21,040 |
The tax is 21,040 divided by 83,200, or 25.3% of modeled capacity. At $7.2 million, that is roughly $1.82 million of capacity-equivalent spend and about 10.1 gross FTE-equivalents. The conversation with the CFO changes from "engineering feels distracted" to "here is exactly where the hours come from."
How Does the Maintenance Tax Become Lost Strategic Capacity?
Every hour spent on the tax is an hour not available for the roadmap, so a measured tax converts directly into delayed milestones or extra hiring requests. The useful question is how many FTE-equivalents you already pay for but cannot consistently deploy against priorities. Answering it makes capacity reclaim a credible alternative to hiring.
Not All of the Tax Is Recoverable
Split the measured hours into three buckets before promising anything. Presenting the full number as savings is the fastest way to lose the CFO.
| Bucket | Examples | Treatment |
| Irreducible | Required patching, unique expert knowledge, unavoidable production stewardship | Keep in the capacity plan |
| Transferable | Routine support, repeat incidents, monitoring, standard changes, minor fixes, release support | Candidate for Application Management and Support |
| Eliminable | Repeat defects, manual deployment work, fragile tests, recurring workarounds | Candidate for delivery acceleration, debt remediation, automation |
Continue the example. Suppose a support model takes 70% of the repeatable ticket, incident, and manual workload (5,432 hours), delivery work removes 20% of debt and fragility hours (2,080 hours), and cleaner support boundaries remove half of context-switching cost (1,440 hours). That reclaims about 8,950 hours, 10.8 points of capacity, or 4.3 FTE-equivalents, worth roughly $775,000 at the assumed loaded cost.
That is capacity reclaim, not automatic cash savings. The value appears only if the freed people move to roadmap work that matters.
Board-Level Burn Rate Metrics
Boards do not need a hundred delivery measures. A short chain linking spend to outcomes is enough.
| Metric | Question it answers |
| Engineering spend per quarter | What are we investing? |
| Maintenance-tax hours and percent of capacity | How much capacity is being consumed? |
| Maintenance-tax dollar equivalent | What is the economic magnitude? |
| Strategic capacity percent | How much of the budget can we deploy against priorities? |
| Repeat-incident and reopen burden | Is support solving causes or recycling symptoms? |
| Reclaimed hours and FTE-equivalents | What is the new model actually freeing? |
| Roadmap throughput after reclaim | Did freed capacity become strategic capacity? |
Pressure to prove returns is rising. Jellyfish's 2026 State of Engineering Management research, covering more than 600 engineering leaders, found that 84% say engineering productivity is a top management concern. It is a vendor survey based on self-reported answers, but it matches the scrutiny CTOs describe from boards.
Why Adding Headcount Often Falls Short
If the tax is structural, new hires enter the same fragile estate, manual workflows, and interrupt-driven support model. Capacity rises briefly and then gets consumed. DORA's 2024 research adds a reason: unstable priorities cause meaningful decreases in productivity and substantial increases in burnout, and a team constantly pulled into production issues has unstable priorities even when the formal roadmap has not changed.
The same applies to coding assistants. DORA's 2024 report found that AI adoption increased individual productivity, flow, and job satisfaction while negatively affecting delivery stability and throughput. Its 2025 research describes AI as an amplifier of existing organizational strengths and weaknesses. More code output does not become strategic capacity if support flow, testing, and ownership stay weak.
When Should You Externalize Application Support?
Externalize when the risk-adjusted value of reclaimed capacity plus avoided support and rework cost exceeds the provider, transition, and retained-governance cost, and when freed people can be redeployed to valuable work. No fixed threshold, such as a specific tax percentage, makes that decision for you.
Compare Total Cost, Not Hourly Rates
The wrong comparison is a vendor hourly rate against a developer salary. The internal status quo includes direct support labor, context-switching cost, rework due to fragility, debt friction, on-call premiums, and the opportunity cost of lost strategic capacity. The external model includes service fees, retained internal expertise and governance, transition and knowledge transfer, vendor management overhead, delivery investment, and the residual tax.
This replaces the weakest argument, that outside labor is cheaper, with a stronger one: a scalable run layer means added support demand does not consume high-value product engineering time.
In-House or Outsourced: A Decision Matrix
| Dimension | Favors in-house | Favors application support | Favors support plus delivery work |
| Differentiation | Daily support produces core product insight | Run work is necessary but not differentiating | Product is strategic, routine operation is not |
| Ticket pattern | Low volume, highly novel | High volume, repeatable, classifiable | High volume plus repeated root causes |
| Context switching | Low, dedicated support exists | Product engineers are often interrupted | Interrupts plus fragile systems |
| Technical debt | Low or manageable | Present, but support is stable | Debt directly drives incidents and rework |
| Coverage | Business hours, predictable | Extended coverage strains the team | Coverage gaps plus modernization need |
| Documentation | Rich and current | Sufficient for clean transfer | Poor, improvable during staged transition |
| Senior talent | Adequate support bench | Seniors act as expensive support labor | Seniors both support and repair structural debt |
Go and Not-Yet Signals
The case is strong when several signals appear together: the measured tax is material, senior engineers regularly handle routine support, demand is repeatable enough to operationalize, support interruptions constrain the roadmap, and a provider can take real responsibility instead of adding a coordination layer.
It is weaker when volume is too small to free meaningful capacity, most tickets need deep proprietary product decisions, vendor coordination would add more switching than it removes, or ownership, access, and runbooks are too unclear to transfer. Poor documentation is both a reason to externalize eventually and a reason not to hand off abruptly. A staged knowledge-capture period beats paying a vendor to rediscover undocumented debt.
Risks Specific to a Lean Engineering Bench
- Thin retained bench. An enterprise keeps architecture and vendor management staff after outsourcing. A mid-market company has less slack, so over-externalizing can leave too little expertise to challenge estimates or exit.
- Knowledge concentration. Moving long-tenured engineers out of support before knowledge capture raises operational risk. Leaving them in the escalation chain forever erases the reclaim.
- Debt contractualized instead of solved. A provider paid for ticket throughput can get efficient at processing symptoms while the same application keeps failing.
- Front-loaded transition cost. Runbooks, access, monitoring, and escalation paths often need work first. Include that cost in the ROI case.
Why Support Alone May Not Fix a High Tax
Two different problems hide inside a high tax. A labor-location problem means good work is being done by scarce engineers who should not be doing it. A structural-fragility problem means the application produces too many tickets, failures, and workarounds in the first place.
Application support addresses the first. Test automation, observability, CI/CD improvements, documentation, dependency updates, and targeted refactoring address the second. Support without delivery work can transfer the tax, while delivery work without support leaves product engineers exposed to every remaining interrupt. Scio's Application Management and Support covers incidents, defects, maintenance, documentation, and key-person risk reduction, and its Software Delivery Acceleration service addresses blockers such as technical debt, quality, and dependencies.
What a Good Contract Should Prove
Service levels alone are not enough. Ask the scorecard to show service (response, restoration, backlog aging), quality (repeat incidents, reopened tickets, failed changes), efficiency (manual steps retired), capacity (internal support hours before and after, FTE-equivalents reclaimed), and strategic outcome (roadmap allocation and predictability).
What This Means for Independent Mid-Market Software Firms
Independent mid-market companies have the least slack to hide the tax. The same scarce engineers answer support requests and build the roadmap, there is no shared services organization to absorb routine work, and a retained bench is thin. That is why the measurement matters before any vendor conversation.
Scio works with independent software companies and takes responsibility for application support through Application Management and Support, with Software Delivery Acceleration available where fragility drives the tax. For a related decision, see our guide to application support versus modernization and our analysis of the true cost of in-house development.
Frequently Asked Questions
What is the maintenance tax in software engineering?
It is the share of engineering capacity consumed by reactive or non-differentiating application support and avoidable friction from the current estate, such as support tickets, incidents, context switching, debt workarounds, and rework due to fragility. It excludes essential run work such as required patching.
What percentage of engineering spend typically goes to maintenance?
No credible universal percentage exists, because sources define maintenance differently. Measure your own components and compare the total with adjacent evidence, such as developer surveys showing 15% to 25% of weekly time lost to non-coding friction. Treat any single industry figure as a rough plausibility check.
How long does it take to measure the tax?
A practical design uses four to six weeks of operational data from your ticket, incident, and delivery systems plus a two-week developer sampling exercise. That is enough to produce a defensible estimate without demanding perfect time sheets from engineers.
Does hiring more engineers fix a high maintenance tax?
Often only for a short time. New hires enter the same fragile estate and interrupt-driven support model, so the tax consumes the added capacity. Reducing or relocating the tax first, then hiring for roadmap work, usually produces a better return.
Which work is best suited to outside application support?
Work with repeatable demand, clear service boundaries, and measurable outcomes: monitoring, routine incident handling, standard operational requests, known-error resolution, runbook-driven changes, release support, and lower-complexity defects. Keep architecture, product decisions, and novel high-risk incidents close to internal owners.
What are the main risks of outsourcing application support?
Transferring undocumented systems, leaving too little internal expertise, adding coordination overhead, and paying for ticket throughput while the same defects return. Mitigate them with staged knowledge capture, retained ownership, and contracts that measure repeat incidents and hours reclaimed, not only response times.
Do AI coding tools reduce the maintenance tax?
Not automatically. Research from DORA shows AI can raise individual productivity while delivery stability suffers when testing and priorities are weak. Tools help most when the surrounding system is healthy, so fix support flow, documentation, and test coverage alongside any tool rollout.
The Bottom Line
A software maintenance cost engineering budget problem is rarely a spending problem alone. It is a capacity accounting problem: hours that look like engineering spend but do not move the roadmap. Measure ticket touch time, context-switching cost, debt friction, and rework due to fragility, then separate what to keep, transfer, or eliminate.
Start with a four to six week measurement sprint and a worked model your CFO can audit. If you want a second pair of eyes on your numbers or on which workloads could move, you can schedule a capacity reclaim conversation with Scio.
References and Further Reading
- Atlassian. State of Developer Experience 2025, a survey of 3,500 developers and managers on time spent coding and time lost to inefficiencies. https://www.atlassian.com/blog/developer/developer-experience-report-2025
- DORA (Google Cloud). Accelerate State of DevOps Report 2024, on AI adoption, delivery stability, and unstable priorities. https://dora.dev/research/2024/dora-report/
- DORA (Google Cloud). State of AI-assisted Software Development 2025, on AI as an amplifier of organizational strengths and weaknesses. https://dora.dev/dora-report-2025/
- Jellyfish. 2026 State of Engineering Management, on engineering productivity as a top management concern. https://jellyfish.co/2026-state-of-engineering-management/
- Paudel, Gonzalez-Huerta, Zabardast, and Klotins. Towards Measuring the Impact of Technical Debt on Lead Time: An Industrial Case Study (2024). https://arxiv.org/abs/2406.01578
- U.S. Bureau of Labor Statistics. Employer Costs for Employee Compensation, June 2026, on the wage and benefit split of compensation costs. https://www.bls.gov/opub/ted/2026/compensation-costs-for-private-industry-workers-averaged-46-89-per-hour-worked-in-june-2026.htm
- Scio. Application Management and Support, on support, maintenance, documentation, and continuity of critical applications. https://sciodev.com/solutions/application-management-support/
- Scio. Software Delivery Acceleration, on focused engineering capacity where delivery is slipping. https://sciodev.com/solutions/delivery-acceleration/
- Scio blog. Application Support vs Modernization Strategy: 5 Real Steps. https://sciodev.com/blog/application-support-vs-modernization-strategy/