What does software maintenance cost per year, and what do you get for it?

Maintenance is the line item buyers understand least, partly because it gets described as insurance. It is a standing budget for four specific kinds of engineering work, and the tier you pick decides how quickly that work happens and how much of it is included before you are quoted separately.

The four kinds of work inside a maintenance contract

Software maintenance pricing models, compared

Before the tiers, the pricing model. Four are in common use and they behave very differently once the system is a few years old.

We price as a percentage of the build, and it is optional. The reason is that it makes the number knowable at signature and decouples the bill from how many people use the system. There is no per-user fee at any tier, and declining maintenance does not switch anything off. The licence is perpetual and the source code is yours either way. The same four models turn up on the licence side of a budget too, which is why the published ERP price comparison ends in a five-year total rather than a monthly figure.

What each tier includes

We do not publish response and resolution times as a blanket figure, and we do not sell an uptime guarantee or run a 24/7 on-call rota. What the tiers differ in is scope and how quickly we commit to answer; the window for each severity level is agreed in writing in your own contract, which is where you should hold anyone to it. If a stopped system at three in the morning costs you money, say so during discovery, because that is a real constraint on us.

How these percentages sit against the published industry figures

The 15% to 25% rule of thumb is repeated across most articles on this subject. It is worth seeing who publishes what, and what each publisher offers as evidence, because the answer changes how much weight the number deserves in your budget.

Two things follow from that table. The first is that the consensus band is a convention rather than a measurement: three publishers, three slightly different ranges, no primary source between them. The second is a caution about treating any single published range as a budget input. The Moonello article gives the break-even point against a subscription stack as 2 to 3 years in its body text and 3 to 4 years in its own key takeaways, on the same page. That is not a criticism of the estimate; it is a reason to price your own case rather than to import someone else's ratio.

Our own numbers are a different kind of object. They are not an estimate of what maintenance costs in the industry. They are the rate we contract at, attached to a written list of what is included, and you can hold us to the list.

The same tiers in money

Because the fee is a percentage of the build, the number is knowable the day you sign. Using the published build bands:

Note what is absent from that table: seat fees. Adding thirty users to a maintained custom system changes the maintenance invoice by nothing, which is the structural difference from a subscription and the reason the five-year comparison looks the way it does.

Which tier fits which situation

• Basic (12%) suits a stable system used by a small number of people for a settled process, where a slower answer on a non-urgent question is fine.
• Professional (18%) suits most operational systems. If work stops when the system stops (dispatching, production reporting, order intake), you want monitoring that tells us before your staff do, plus a few hours a month for the adjustments that always accumulate.
• Comprehensive (25%) suits systems used by people outside your company, such as dealers or customers, and systems still growing month by month.

What the maintenance fee actually pays for

A percentage is an abstraction, and abstractions are easy to resent in a quiet year. It is more useful to split the fee into two categories: work that genuinely gets done, and standing capacity you are reserving whether or not you use it. Both are legitimate. Only one of them feels like value in a month when nothing breaks.

Do the arithmetic on your own case rather than taking the percentage on faith. On a $15,000 build the Professional tier is $2,700 a year and carries 48 development hours plus everything marked as scheduled work above. Price those 48 hours against whatever a contract developer costs where you are, subtract, and what remains is what you are paying for availability and monitoring. If that remainder looks large for your situation, the Basic tier exists precisely because the trade is not the same for everyone. This is the calculation a vendor is supposed to help you run, and it is one of the questions worth asking before you sign.

What maintenance is not

Maintenance keeps the delivered system correct, secure and current. It does not silently absorb new scope: a new module, a new integration or a redesign of an existing workflow is quoted as new work against the same drivers as the original build. We would rather say where that line is before you sign than argue about it afterwards. Backups are run and tested under every tier, but where your data lives and who can reach it is a separate decision, covered in where your data actually lives.

What happens if you skip it

The honest answer is: not much, at first. A delivered system with no maintenance contract keeps doing exactly what it did on the day it went live, and you hold the source code, so you can hire anyone to work on it. What changes is slower and less visible:

• The platform moves and the software does not. Browsers and mobile operating systems ship changes several times a year. Most are harmless; occasionally one breaks a file upload or a print layout, for everyone at once.
• Dependencies fall out of security support. Upgrading one version at a time is routine; upgrading four years at once is a project.
• Data volume outgrows the original design. Adding an index in advance takes minutes; diagnosing a slow query during month-end does not.
• Nobody is watching. Without monitoring, the first person to notice an outage is a customer, and the first person to notice a failed backup is you, on the day you need it.

If you have your own developer who follows dependency releases and runs restore tests, none of this needs us. If nobody currently owns those tasks, that is the argument for a contract, not a story about inevitable disaster.

What happens if you stop paying for maintenance

This is the question buyers ask last and worry about first, because in most software purchases the answer is that things switch off. It is worth separating what a maintenance contract is from what a licence is, since a subscription bundles them and this model does not.

What does not change on the day the contract ends

• The software keeps running, exactly as it ran the day before. There is no licence key to expire and no kill switch, because there is no licence server for us to switch off. The build was delivered, not rented.
• The licence stays perpetual and unlimited-user. Ending maintenance does not reduce your seat count, gate a module, or convert anything to read-only.
• You keep the source code, the database schema and the documentation. Those were transferred at delivery rather than at the end, which is also why we do not use source-code escrow: nothing is being held that a third party would need to hold.
• Your data stays where it already is. It is in your database, on your server, in a schema you have documentation for. There is no export window and no proprietary format to escape.
• The accounts stay in your name. Repository, server, domain, DNS and third-party services were set up in your organisation's name with us as a removable user.
• You can come back, or not. Restarting maintenance later is a new agreement, not a penalty. Hiring somebody else is not a breach of anything.

What you actually lose, stated plainly

• The response commitment. Report a bug and there is no agreed window in which anyone answers. This is the real loss, and it is felt on the worst day rather than on an average one.
• The included development hours. 48 a year at the 18% tier, 96 at 25%. Small changes go back to being quoted individually.
• Monitoring and alerting. If the uptime monitoring runs from our side, it stops when the contract does. Nobody is watching the system on your behalf, so the first notice of an outage arrives from whoever tried to use it.
• Scheduled dependency and security patching. Nobody is tracking advisories for your stack. This is the item that does the most quiet damage over three years.
• Restore testing. Your backups may well keep running on their schedule, but nobody is proving they restore. An untested backup is still a belief.
• The annual technical review at the 25% tier.

None of that is trivial and we are not going to pretend otherwise. The difference is what kind of decision you are making. Everything in the second list is work, and work can be bought from anyone or done in house, because the code, the schema and the credentials are already yours. In a per-seat subscription the equivalent decision is not who does the work; it is whether the software keeps running at all. That is the structural point behind the move from subscription to owned software, and it is the only reason a vendor can answer this question honestly.

One caveat to settle before you sign rather than after. Everything above is true because the infrastructure is billed to you. If any part of a running system sits on an account billed to your vendor (a hosting plan, a domain, a mail relay, a paid API key), then ending the contract touches those too. Our default is that all of it is in your name from day one. Check that it is, in writing, whoever you buy from.

Handing maintenance to another team

The cleanest test of any vendor relationship is how short the handover would be if you ended it tomorrow. That is not a legal question about who owns the copyright, though that matters too. It is a delivery question about what is already in your possession. Buyer-side due-diligence lists put it before signature rather than after. The 35-question vendor checklist published by Pragmatic Coders asks when code ownership transfers and whether you have repository access from day one, and separately what handing the project to another team would look like, how long it would take, and what you would receive.

Here is what has to exist for the answer to be short.

1. The repository, with its history, in an account you own

   Not a zip file emailed at the end of the project. Commit history is how a new team learns why the code is shaped the way it is, and losing it converts reading into guessing.

2. Build and deployment scripts

   The exact commands that turn the repository into a running system, in the repository itself. Without them, a new team reverse-engineers your deployment before it fixes a single bug.

3. Environment configuration, documented

   Every environment variable, service, queue and connection the system needs in order to start, with the values held by you. Secrets should be rotated at handover as a matter of routine, not as an accusation.

4. Database schema and migrations, versioned

   The schema as a set of migration files that can rebuild an empty environment, not only as a production dump. This is what lets a new team build a test environment on day one instead of week three.

5. An architecture overview and the open issues list

   A short document explaining how the parts fit together, plus an honest backlog of what is known to be broken or deferred. A tidy backlog handed over is worth more than a clean one that was emptied for the occasion.

6. Ownership of every account, in your organisation's name

   Repository, server, domain, DNS, TLS certificates, third-party service accounts, API keys and the deployment pipeline. Each one in your name with the vendor added as a user who can be removed, rather than the other way round. This is the same test as in code ownership and lock-in.

7. A knowledge transfer session, with a date in the contract

   Time with the people who wrote it, scheduled rather than promised. An hour with the original developer saves a new team days of reading.

That list is not ours alone. Published handover guidance from Virtuous Techlogic describes the minimum bundle in almost the same terms: repositories, build instructions, environment documentation, third-party account transfers where applicable and a defined support period, with an API key rotation plan, an architecture overview and the open issues backlog named explicitly.

Worth knowing before you negotiate any of it: paying for development does not by itself make you the owner of the code. UK buyer-side guidance from Talk Think Do states that in most jurisdictions the developer retains copyright unless the contract explicitly assigns it, and that "most custom-built applications default to licensing rather than ownership" (Talk Think Do). That has to be settled in the agreement before the build starts. Our contracts transfer source code, database schema and documentation on delivery, which is a different arrangement, and the only reason the handover list above is answerable at all.

When you should not buy a maintenance contract

A maintenance line nobody uses and nobody wanted is the fastest way to make a working system feel expensive. There are five situations where we would tell you to skip it, or at least to wait.

• You already employ someone who does this work. If a developer on your payroll follows dependency releases, applies patches and tests restores, a contract buys you a second copy of a job you are already paying for. Buy incident-only access instead, or nothing.
• The system is small, internal and genuinely stable. A single-module tool used by four people for a settled process, on a stack whose dependencies move slowly, can sit for a year without anything needing to happen. Wait until there is work, then pay for the work.
• You intend to replace or substantially rebuild it inside a year. Maintaining an asset with a known retirement date is spending against something you have already decided to stop using. Keep the budget for the replacement.
• The system has no real users yet. Faults are discovered by use. A system that is live but not yet in daily use is not generating the tickets a contract exists to answer. Start the clock when the system starts carrying real work.
• Nobody can describe what they would call about. If your team cannot name the failure that would prompt a call, the contract is being bought on anxiety rather than on need. Buy the first period, keep the ticket log, and price the second year against what actually happened.

The case that most reliably justifies a contract is the inverse of all five: the system is in daily use, work stops when it stops, and nobody on your payroll currently owns dependency upgrades or restore testing. If that describes you, the argument is not that something terrible will otherwise happen. It is that the work exists either way and someone has to be responsible for it.

What to check before signing

1. Response and resolution windows, per severity

   A single "we respond quickly" clause is worthless. Get the hours in writing for a full outage, a degraded module and a cosmetic defect.

2. Included hours and whether they roll over

   Four hours a month is useful if a quiet month can fund a busier one. Ask, and get the answer in the contract.

3. Who holds the keys

   Server access, domain, database credentials and repository ownership should be in your name from day one, with the vendor as a user. This is the same test as in code ownership and lock-in.

4. What monitoring runs and who is alerted

   Ask what is checked, how often, and whether your team is on the alert list too.

5. The exit terms

   Notice period, handover contents, and confirmation that ending maintenance does not affect your licence or your access to the code.

6. What stops on the last day, item by item

   Ask the vendor to write down what ends when the contract ends, and what does not. If the answer includes the software itself, you are buying a subscription with a maintenance label on it, and the five-year arithmetic is a different calculation.

Sources

• Rorix, software maintenance cost (rorixtech.com) for the 15% to 25% band
• Appinventiv, software maintenance cost (appinventiv.com) for 15% to 25% and the $5,000 to $20,000 annual range
• Moonello, what is software maintenance (moonello.com) for 10% to 20% and the break-even figures
• Talk Think Do, software source code ownership (talkthinkdo.com) for default copyright ownership and licensing
• Virtuous Techlogic, source code ownership and handover (virtuoustechlogic.com) for the handover bundle contents
• Pragmatic Coders, 35 questions to ask a software vendor before signing (pragmaticcoders.com) for the ownership and vendor-switching questions
• KodDelta pricing, maintenance tiers and delivery bands

Sources checked in August 2026. Third-party figures are each publisher's own estimate as shown on the linked page at the time of checking; where a page cites no source of its own, that is recorded rather than filled in. Company names belong to their respective owners, and KodDelta is not a partner or reseller of any organisation listed here.

The tiers, the build bands and what sits inside each are published on our pricing page. If you want a maintenance figure against a system you already own, describe it on the quote form, and if the honest answer for your situation is that you do not need a contract yet, we will say so.

Frequently asked questions

What are the common software maintenance pricing models?

Four are in general use: a percentage of the original build cost charged annually, time and materials billed as work happens, a monthly retainer buying a block of hours, and a per-user or per-seat subscription. KodDelta uses the percentage model at 12%, 18% or 25% of build cost, because it fixes the number at signature and does not grow with your headcount. Time and materials is the least predictable, and per-seat is the one that compounds as you succeed.

How much does software maintenance cost per year?

It is priced as a percentage of the original build cost: 12% for the basic tier, 18% for professional and 25% for comprehensive. On a $15,000 build that is $1,800, $2,700 or $3,750 a year. The percentage is of the build, not a licence, and there are no per-user fees.

What is the difference between the 12%, 18% and 25% tiers?

The 12% tier covers bug fixes, compatibility updates, security patches and email support. The 18% tier adds four development hours a month, uptime monitoring and priority phone support. The 25% tier adds eight development hours a month, the shortest response window we agree to and an annual technical review. We do not publish response times as a blanket guarantee and we do not sell an uptime guarantee; the window for each severity level is written into your own contract.

Is maintenance mandatory?

No. The first period is included with the build; after that it is optional. If you decline it the system keeps running as delivered, you keep the source code, and you can maintain it with your own developer. What you lose is our response commitment and the monthly development hours.

What happens if I stop paying for maintenance?

The system keeps running exactly as delivered. There is no licence key to expire and no kill switch, because the licence is perpetual and the source code, database schema and documentation were transferred at delivery. What ends on that date is our response commitment, the included development hours, the monitoring we run, scheduled dependency and security patching, and restore testing of your backups. Every item on that list is work you can buy elsewhere or do in house, because the code, the server and the credentials are already in your name.

Can another company take over maintenance of software you built?

Yes, and it needs no permission from us. What decides whether the handover takes an afternoon or a quarter is what was delivered during the build: the repository with its commit history, build and deployment scripts, documented environment configuration, versioned database migrations, an architecture overview and the open issues list, plus ownership of the server, domain, third-party accounts and API keys in your organisation's name. If those exist, a competent team can pick the system up. If they do not, the handover becomes a reverse-engineering project no matter who holds the copyright.

Is 15% to 25% a real industry standard for maintenance?

It is a widely repeated convention rather than a measurement. Rorix publishes 15% to 25% of the original build cost per year and describes it on the page as a rule of thumb; Appinventiv publishes the same band; Moonello publishes 10% to 20%. None of the three cites a source for the figure. Our 12%, 18% and 25% are contract rates attached to defined tiers rather than an estimate of what maintenance ought to cost in general.

When should I not buy a maintenance contract?

When you already employ a developer who follows dependency releases and tests restores; when the system is small, internal and stable on a slow-moving stack; when you intend to replace it inside a year; when it has no real users yet, so faults are not being discovered; or when nobody can describe the failure that would prompt a call. In that last case buy the first period, keep the ticket log, and price the second year against what actually happened rather than against a percentage.

Does paying for custom software make me the owner of the code?

Not automatically. Buyer-side guidance published in the UK notes that in most jurisdictions the developer keeps copyright unless the contract explicitly assigns it, and that custom builds default to a licence rather than to ownership. It has to be written into the agreement before the build starts, not negotiated at the exit. KodDelta contracts transfer the source code, database schema and documentation on delivery, and we do not use escrow because nothing is held back to escrow.

What is not covered by a maintenance contract?

New modules and substantial new functionality are quoted as separate work. Maintenance keeps the delivered system correct, secure and current, plus a small monthly allowance for adjustments. Adding a warehouse module to a purchasing system is a project, not a maintenance ticket.

What actually happens if software goes unmaintained for a few years?

Nothing dramatic on day one. Over time three things drift: browser and mobile updates break parts of the interface, dependency versions fall out of security support, and tables that were fast at ten thousand rows become slow at a million. None of these announce themselves.

What should a maintenance contract state in writing?

The response and resolution window for each severity level, the development hours included per month and whether they carry over, who holds the deployment credentials, what monitoring runs and who receives the alerts, and the notice period for ending the agreement.