The order management system went live in early 2024. It runs on .NET 8 with an Angular frontend, and it works: no complaints, and the last invoice from the vendor was the one closing out the warranty. On November 10, 2026, .NET 8 stopped getting security patches from Microsoft. Nobody at the company noticed, because noticing wasn't anyone's job.
Custom software development doesn't end on delivery day. That's when a longer and much less visible phase starts, one where the system needs bug fixes, changes to keep up with the business, updates to its components and someone keeping an eye on it. This article covers that phase: the types of software maintenance, what expires even if nobody touches the code, and how to budget for custom software support year after year. What it costs to build is covered in what drives the cost of a custom application. Here we pick up from go-live.
A warranty is not maintenance
Almost every development contract includes a warranty period after delivery. During that time the vendor fixes defects at no cost, meaning anything that doesn't work according to the agreed acceptance criteria.
What a warranty usually doesn't cover:
- New features or changes to business rules.
- Upgrading the framework, libraries or runtime.
- Failures caused by changes in external systems, like the ERP or a bank's API.
- Operations: hosting, backups, monitoring, certificate renewals.
Check your contract for when the warranty ends and what happens the day after. If it says nothing, each later request usually gets quoted separately, which ends up slower and more expensive than an annual agreement. What you should have received at project close (source code, documentation, access) is listed in software development stages and deliverables. Without it, maintaining the system gets hard for anyone, the original vendor included.
Four types of software maintenance
Maintenance isn't only "fixing what breaks." It helps to split it into four types, because each one is budgeted differently.
| Type | What it is | Example | How to budget it |
|---|---|---|---|
| Corrective | Fixing bugs that show up in production | A report that adds up wrong when there are credit notes | Pool of hours with agreed response times |
| Adaptive | Adjusting the system to changes around it | The bank changes its payment file format | Pool of hours; hard to predict |
| Evolutive | New features the business asks for | Adding an approval flow for discounts | Prioritized backlog with an annual budget |
| Preventive | Updating dependencies and paying down technical debt | Moving from .NET 8 to .NET 10 | Fixed annual plan |
Preventive work is the one that gets pushed back the most, because nobody sees it. It's also what keeps the other three from getting expensive: a system that's up to date is faster to fix and change than one that's three versions behind.
What expires even if nobody touches the code
The frameworks and runtimes your system is built on have their own calendars. A few examples, using the dates each project publishes:
- .NET. Under Microsoft's support policy, LTS releases are supported for at least three years and STS releases for 24 months. .NET 8 and .NET 9 went out of support on November 10, 2026; .NET 10 is supported until November 2028. Patches ship monthly, with security fixes on the second Tuesday of each month.
- Angular. Starting with version 22, it ships a major version every 12 months (it used to be six). Each one gets 24 months of support: 12 active and 12 LTS, when it only receives critical and security fixes. Angular 20 leaves LTS on November 28, 2026. One catch:
ng updatemoves one major version at a time, so if you skipped three, that's three migrations. - Node.js. The project recommends running only LTS versions in production, which get critical fixes for about 30 months in total. Node.js 20 has been end of life since March 2026.
Then add the npm or NuGet packages, Docker base images, TLS certificates and third-party APIs the system depends on. Each one moves at its own pace.
An unsupported system still runs the next day. The trouble starts when a vulnerability is published and nobody ships a patch for your version. At that point, an upgrade that would have taken an afternoon turns into a project with a quote, a timeline and regression testing.
Operations: hosting, monitoring and backups
Beyond the code, someone has to make sure the system stays up. These are the questions worth having answered in writing:
- Whose name is the hosting subscription under, and who has admin access? Ideally it belongs to your company, with the vendor as a guest user.
- Who gets the alerts if the system goes down on a Sunday, and how fast do they respond?
- How often are backups taken, how long are they kept, and when did someone last try restoring one? A backup nobody has ever restored is an assumption.
- Who can access production, and is what they do logged?
- Where does the code repository live? If it's in the vendor's account, move it.
If the system handles personal data about customers or employees, this is a legal matter too. Chile's Law 21,719 includes a duty to adopt security measures and to report breaches. It is still set to take effect on December 1, 2026. On October 28 the Senate passed a bill that moves that date to October 15, 2027, and in early November the Constitution Committee of the Chamber of Deputies approved it in general and sent it to the Finance Committee. Until it's published, the date stands. Either way, an unpatched system is hard to defend as a "security measure."
How to budget for custom software support
Some people use a percentage of the development cost as a rule of thumb. That's fine for starting the conversation, but the real number depends on how many components the system has, how many integrations, and how much you want it to keep changing. An order that works:
- Build an inventory of components with their version and end-of-support date. A spreadsheet will do.
- Lay out an upgrade calendar from those dates. For example: Angular once a year, .NET whenever a new LTS comes out.
- Separate fixed costs (hosting, monitoring, preventive maintenance hours) from variable ones (corrective and adaptive).
- For the variable part, agree on a monthly pool of hours with response times by severity. Decide what happens to unused hours.
- Keep evolutive work in a separate budget, as a prioritized backlog. If it's mixed with corrective work, urgent fixes eat the improvements.
- Once a year, review hours used, incidents and technical debt, and adjust.
A useful support contract spells out the scope, response times, the maintenance window, whether version upgrades are included, and who owns the code and the accounts.
Frequently asked questions
How long is the warranty on custom software?
There's no standard term; it depends on what you sign. More than the length, check what it covers (defects measured against the acceptance criteria) and what happens when it ends.
Can I leave the system un-upgraded if it works fine?
You can, but it runs without security patches, and every year you wait the upgrade costs more. With Angular, for example, you have to move one major version at a time.
Does the team that built the system have to maintain it?
No. With the code, documentation and access, another team can take it over. The people who built it usually know it best, but what matters is that the code and accounts are in your company's name.
Think about "after" before you start
At Disrupsoft we design and build custom web and mobile applications with Angular, Node.js, Azure and Power Platform, and we stay in constant contact with your team throughout the project. If you're about to start a development project and want to settle from day one how it will be maintained, let's talk about your custom software development project.
