Is hosting included in custom software maintenance?

Usually not, and you should check. Hosting, database storage, email sending, SMS credits and any paid APIs are running costs billed by those providers, separate from the hours someone spends keeping the app current. Ask for the two to be listed apart on every quote. Infrastructure bills grow quietly with usage, and a maintenance figure that silently includes them makes the development effort look larger than it is.

Can our own IT person handle the maintenance instead?

Sometimes, and it depends on which work you mean. Applying patches, watching error reports and renewing certificates are well within reach of a capable internal person with access and documentation. Major version upgrades of a framework or database usually are not, because they need someone who can read a migration guide, fix what breaks and prove the app still works. A sensible split is internal monitoring with outside help booked for the dated upgrades.

How long does custom software last before it needs rebuilding?

Well-maintained software does not have a fixed expiry date, and a rebuild is usually a symptom rather than a milestone. Apps that get upgraded each year can run for a decade or more, because no single jump is ever large. Apps left untouched tend to reach a point, often around four or five years, where the dependencies are so far behind that replacing is cheaper than catching up. The maintenance decision and the rebuild decision are the same decision at different times.

Who is responsible if our custom app is breached?

Responsibility depends on your contract and on the data protection law that applies to you, so read both rather than assuming. In broad terms the business operating the app answers to its customers and regulators for the data it holds, while a developer's duty is set by what the agreement says about security work and support. If your contract says nothing about patching, nobody has agreed to do it. Fix that before you need it.

What does custom software maintenance cost each year?

Say you run a flooring contractor in Phoenix with eleven crews and a job costing tool a developer built you in 2021. It works. Nobody has touched it in two years. Then the developer emails: the version of Node.js, the runtime your code executes on, stopped getting security patches in April, your host will force an upgrade in January, and the work is nine days.

Nine days, on an app nobody changed.

Custom software maintenance cost usually gets quoted as 15 to 25 percent of the build cost per year, which is a rule of thumb rather than a measurement. The honest way to estimate it is to read a calendar: list the end-of-life dates for the runtime, the database, the libraries and the paid services your app plugs into, then price the hours each forced upgrade takes. Those dates are published years ahead, so next year's bill is mostly knowable today.

The percentage sounds like a service plan. It is really a guess at how much of someone else's schedule you are about to inherit.

Why does custom software need maintenance if nothing changed?

Because your code didn't change and everything underneath it did.

A custom app is a thin layer of your logic sitting on a deep stack of other people's work: the runtime, the database engine, the web framework, the authentication library, the PDF generator, the payment SDK (the vendor's own code library, bundled into yours). Every one of those has its own release schedule and its own support window, and none of them asks your permission.

Black Duck's 2026 Open Source Security and Risk Analysis report audited 947 commercial codebases. In 92 percent of them, open source components were four or more years out of date. The median component age was 45 months, and only 7 percent of components in use were on their latest version.

Drift has a price now. The 2026 Verizon Data Breach Investigations Report put exploitation of vulnerabilities at 31 percent of initial access in breaches, ahead of credential abuse at 13 percent. Attackers are not picking locks. They're walking through doors that shipped with a known defect and a patch nobody applied.

What am I actually paying for in a maintenance retainer?

Four kinds of work, and they are worth separating on the invoice:

Security patches and dependency updates. Small, frequent, mostly automated by tools like Dependabot or Renovate, but each one still needs a human to read the changelog and run the tests.
Platform upgrades with a deadline. The runtime major version, the database major version, the mobile SDK. These have dates attached and cannot be declined.
Breakage caused by other people's decisions. An API, the published connection one system offers another, deprecates a field. An OAuth provider, the sign-in standard behind those "continue with Google" buttons, tightens its scopes. A certificate expires. None of this is in your plan, and all of it lands on a Tuesday.
Someone who answers at 7am. The part that feels like insurance until the day it isn't.

What a retainer should not quietly become

A feature budget. We meet it in most handover conversations: a retainer spent on small changes, month after month, while the upgrades sit undone. The client is happy, because things keep getting added. Then year three arrives, the runtime is two major versions behind, and the catch-up gets priced as a surprise.

Ask for the month's hours split into maintenance and changes. If maintenance reads zero for three months running, you're paying for development and calling it protection.

Four blocks rising from patch to upgrade to rebuild, showing how deferred maintenance compounds into one expensive jump.

How do I budget custom software maintenance cost for next year?

Build the calendar first, then price it. The exercise takes about an hour with whoever maintains the app, and it replaces the percentage with a list.

Write down your runtime and its end-of-life date. Node.js 22, one of the long-term support lines that still get fixes, stops receiving support on 30 April 2027, and Node.js 24 runs to 30 April 2028, per the Node.js release schedule. Node.js 20 already went end-of-life on 30 April 2026, so if you are on it, the work is overdue rather than upcoming.
Write down your database version and its date. PostgreSQL 14 reaches end of life on 12 November 2026 under the project's five-year versioning policy, with version 15 following in November 2027.
List every paid API and third-party SDK, then check each changelog for deprecation notices. Payment providers and messaging platforms do give notice, by email, to whoever registered the account, who is often someone who left.
Ask for hours against each date, not a percentage of anything. A minor version bump is hours. A major version jump is days, sometimes a week, because major versions are where maintainers remove things.
Add a contingency for the one big jump. In semantic versioning, the scheme most libraries publish under, the major number is a warning that breaking changes are permitted. Whichever year yours lands is the expensive year.

That gives you a budget with dates in it. A quiet internal tool on a current stack might need three or four days across the year. The same tool two versions behind, with a payment integration and a public login, is a different conversation, and better to have in October than in January when your host picks the date for you.

One honest caveat on step 4. We cannot always tell in advance which upgrades go badly. Most major version jumps are a day of mechanical changes, and then one turns into a week because a dependency was abandoned years ago and has to be replaced. We quote a range for that reason, and we are sometimes wrong at the top of it.

What happens if you skip maintenance for two years?

The work doesn't go away. It compounds, and it loses its schedule.

Upgrades done yearly are incremental: one version, a changelog, a test run. Upgrades deferred for two or three years stop being incremental, because you can no longer step through versions that are themselves unsupported by then. You jump, and the test plan becomes whatever your staff report on Monday.

Say you run a recruitment firm in Manchester, and your consultants spend the day inside a candidate portal built for you four years ago. The portal is fine. Then your hosting provider announces that the database version under it gets upgraded automatically on a date in your busiest month, because their own support window closed. You didn't choose that date. You inherited it, and the testing now has to happen in two weeks instead of two months.

Security is the other half of the answer. The OWASP Top 10, the standard reference for application security risk, was revised on 6 November 2025, and its A03 category is now Software Supply Chain Failures, widened to cover dependencies, build systems and distribution.

You can skip a year, once, on a tool with no public login and no card data. Skip two and you have turned a maintenance line into a capital expense.

What changes for software maintenance in 2027?

The EU Cyber Resilience Act, Regulation (EU) 2024/2847, applies in full on 11 December 2027, and its vulnerability reporting duties for manufacturers started on 11 September 2026. The provision that matters to you is the support period. As a general rule the regulation requires at least five years of security updates for products with digital elements. The manufacturer sets that period and documents it, based on how long the product is expected to be in use.

Read that as a buyer rather than as a builder. A one-off internal tool built for you is largely outside the scope, because you are not placing a product on the EU market. The commercial software underneath it is squarely inside. By the end of 2027, the vendors of your components and platforms will have had to state how long they will support what they sold you, which turns a guess into a document you can ask for.

Two things to do now, both cheap. Ask every current vendor for their stated support period and keep the answers in one file. Then ask whoever maintains your app for a software bill of materials, a machine-readable inventory of every component and version in the build, in CycloneDX or SPDX format. Without one, "are we affected by this week's vulnerability" takes a day to answer. With one, it takes ten minutes.

When a maintenance retainer isn't worth paying for

When the tool is internal only, reachable only on the office network, holds no card data and no personal data beyond staff names, and already sits on a current stack. Then a monthly retainer will mostly idle, and we would rather say so than sell one.

Buy a scheduled block of upgrade work once or twice a year instead, aimed at the dates on your calendar, and keep a number to call when something breaks. That is less revenue for us and the right answer for you.

The calculation flips the moment any one of these is true: customers log in, card or health data is stored, an integration is load-bearing for billing, or an hour of downtime costs real money. Then you are not buying patches. You're buying a response time.

It also flips when the person who understood the app has left. Knowledge living in one head is the most expensive dependency in the system, and it has no published end-of-life date.

What to do this week

Open a document and write down four things: your runtime and its version, your database and its version, every third-party API the app calls, and the date updates were last applied. If you can't fill in the fourth, that is the finding.

Send it to whoever built the app and ask for hours against each end-of-life date in the next 18 months. You will get a short list of planned work, or you will get silence, and both tell you something. If nobody is sure what is in there, start with an audit rather than a retainer. Two things worth reading before you need them: who owns custom software code after you've paid for it, on who is even allowed to do this work, and when to stop vibe coding and bring in a developer, on the prototype that became load-bearing. The same silent decay hits automations, which is how to tell if an automation stopped working.

If you want a second opinion, send us those four lines through our contact page, or read what a custom software build covers after launch. Tell us the stack and the last update date. We'll tell you what is coming and roughly what it costs, and if you don't need us for eight months, we'll say that.