Build and forget? In 2026, a lack of updates can kill an application
Application deployment is often treated like crossing the finish line. The project has been completed, the system works, users can log in, orders are flowing, integrations respond, and the team moves on to the next tasks.
A very tempting assumption then appears: if it works, better not touch it. Just a few years ago, such an approach could be considered cautious for a while. In 2026, however, it increasingly means consciously building up risk.
Because the application may not change, but practically everything around it does: operating systems, browsers, open-source libraries, frameworks, third-party APIs, cloud infrastructure, security standards, and methods used by cybercriminals.
As a result, a system that works correctly today may be difficult to develop, expensive to maintain, incompatible with the current environment, and full of known vulnerabilities in two years. The “Set It and Forget It” myth, or “build and forget,” is therefore one of the most costly ways of thinking about software.
The application is not a finished product
A modern application practically never consists solely of code written by one team. Underneath, there are, among others:
Even if we do not change a single line of our own code for 12 months, part of this ecosystem will have received new versions, security patches, API changes, or ended its official support period. That is why the statement: “We are not developing the application, so we don’t have to update it” is technically very dangerous.
A lack of functional development does not mean a lack of the need for maintenance. If an application is a critical business component, it should be treated like infrastructure that requires regular inspection. At DevQube, this is exactly why we treat software development and maintenance as part of the entire product lifecycle, not a service needed only when the system stops working.
Problem number 1: known vulnerabilities don’t disappear just because the application works
The most obvious argument for updates is security. In the OWASP Top 10:2025, threats related to the software supply chain were ranked very high – the Software Supply Chain Failures category takes the A03 position. This is an important change in the way we look at application security.
The problem is no longer just the code written by developers. The problem can also be the components that have been attached to it. Imagine an application with 30 direct dependencies. Each of them can use further libraries. In practice, the system may contain hundreds of components that the application owner never consciously chose.
If a critical vulnerability appears in one of them, the application can become vulnerable without any change to its own code.
Log4Shell perfectly demonstrated the scale of the problem
One of the best-known examples remains the Log4Shell vulnerability – CVE-2021-44228 – regarding the Log4j library. The problem was serious not only because under certain conditions it allowed remote code execution.
A much bigger challenge turned out to be determining: where exactly is Log4j used? The library was often located several levels deeper in the dependency tree. Companies discovered that the component was in the application, even though their team never installed it directly.
What’s more, the vulnerability was exploited long after the information and patches were published. CISA documented attacks on still unpatched systems available publicly. And this is exactly the core of the problem. Cybercriminals do not stop exploiting a vulnerability because it is “old.” On the contrary – a system for which a publicly available exploit exists, and which has not been updated for years, can be an exceptionally easy target.
Problem number 2: update debt is created
Technical debt is a concept well known to most technology teams. However, update debt is talked about much less frequently. And its mechanism is very similar.
Updating a library: 3.2.1 to 3.2.2 may take a few minutes of work and running tests. Moving from 3.x to 7.x after four years of neglect may require rebuilding significant parts of the application. The same applies to frameworks, programming languages, or databases.
If the system is updated regularly, changes are made in small steps. If updates are postponed for a few years, the team may face the need to simultaneously solve dozens of problems:
- changed APIs,
- removed functions,
- unsupported libraries,
- conflicting dependencies,
- new security mechanisms,
- changed configurations,
- lack of compatibility with the new environment.
Then something that could have been ongoing maintenance becomes a full-fledged modernization project. And this is exactly why postponing updates often does not mean savings. It means pushing the cost into the future – usually with additional interest.
“But the system works” – this is one of the most dangerous diagnoses
The system can simultaneously:
- serve clients,
- have critical vulnerabilities,
- run on an unsupported runtime version,
- use libraries without active maintainers,
- lack up-to-date tests,
- have no documentation,
- be impossible for a new developer to run locally.
As long as nothing needs to be changed, the problem remains invisible. The moment of truth usually occurs when the business urgently needs something. A new integration. Support for another market. A change of payment provider. A new feature. AI integration. Adapting the application to a new process.
Then it turns out that before adding functionality, you first need to spend weeks bringing the project to a state where development can safely begin at all. This is one of the typical scenarios leading to working with legacy code and its gradual modernization.
Problem number 3: the application’s environment also updates
Not all problems stem from vulnerabilities. Sometimes an application simply starts functioning in an environment for which it was never designed.
Browsers change
Chrome, Safari, Firefox, and Edge are constantly developing their rendering engines, security policies, and privacy protection mechanisms. Among other things, the following change:
An application that remains unupdated for years may therefore behave differently not because someone changed its code, but because the user’s browser changed.
Mobile systems change
This is even more visible in mobile applications. Apple and Google regularly change the requirements for applications published in stores, SDK versions, privacy, security, and the use of individual device features. That is why the lifecycle of a mobile application does not end with its publication in the App Store and Google Play. If you are planning such a product, it is worth thinking about its maintenance already during the design phase. We describe the entire process more broadly in our guide on how to create a mobile application in 2026.
External APIs aren’t eternal either
A system can be built correctly but use a dozen or so external services:
Each of these providers can change their API or deprecate its old version. Thus, the application doesn’t even need to be touched for some of its functions to stop working one day.
Problem number 4: updating after a few years is much riskier
Paradoxically, a frequent argument against updates is: “We don’t update because we’re afraid something will break.” The problem is that this is a strategy that over time increases exactly that risk.
If we update a small library every few weeks, the scope of change is usually limited. If we upgrade the entire system after four years, dozens of elements change simultaneously. It is then harder to answer the fundamental question: what exactly caused the regression?
That is why modern maintenance should not consist of organizing a massive action once a year under the slogan “we update everything.” Small, regular updates combined with automated tests are much more effective.
So the conclusion does not sound like: Always install the latest version immediately. A better rule is: Update regularly, but treat updates like any other code change. They should go through:
As long as such a process allows combining security with risk control.
Maintenance automation changes the rules of the game
The good news is that regular maintenance of dependencies doesn’t have to mean manually browsing hundreds of pages with information about new versions. A large part of this process can be automated.
Dependabot and Renovate
Tools like Dependabot or Renovate can automatically detect new versions of dependencies and prepare pull requests. Thanks to this, the team can receive a small change: “Update library X from version 4.2.1 to 4.2.2” instead of performing the task: “Update all project dependencies” after two years. The difference is huge.
Software Composition Analysis
SCA (Software Composition Analysis) class tools allow analyzing application dependencies for known vulnerabilities. A popular example is OWASP Dependency-Check. If a CVE appears in a used component, the team can get information about the problem before someone tries to use it against the system.
SBOM, or the list of application ingredients
The Software Bill of Materials also plays an increasingly important role. Put simply, it is a list of components used in a given software version. Thanks to this, when a new critical vulnerability appears, the organization can quickly answer: Are we using this component? and: In which systems and versions? Without such a mechanism, analysis might mean manually browsing many repositories.
The law is also starting to require thinking about the entire product lifecycle
Updates are increasingly ceasing to be merely a matter of good technical practice. In the European Union, a significant change is brought by the Cyber Resilience Act. The regulation covers certain products with digital elements and introduces requirements related to cybersecurity and vulnerability management in the product lifecycle. Some of the obligations regarding reporting actively exploited vulnerabilities and severe incidents will apply from September 11, 2026, while the main CRA obligations will come into force on December 11, 2027.
Of course, this does not mean that every web application is automatically subject to the CRA. However, it shows a clear direction of change. Product security is increasingly viewed as an ongoing process throughout its period of use, rather than a one-time audit before release.
Regular updates are cheaper than a rescue mission
Maintenance cost is often perceived as an expense that can be reduced. In the short term, it does look like that. If we don’t update the system for a year, the company does not incur costs associated with this work. The problem appears later. Imagine two systems built on the same framework.
After four years, both systems must move to the current version of the technology. In system A, this will be just another stage of maintenance. In system B, it could become a multi-month project. On top of this is the business risk that existed throughout the period of neglect. That’s why the question shouldn’t be: “How much does application maintenance cost?” It’s better to ask: “How much will a lack of application maintenance cost?”
What should reasonable application maintenance look like?
Not every application needs daily updates. Nor does every company need a large DevSecOps department. The process should be tailored to the system’s importance. We will maintain a simple internal application used by ten people differently than a platform handling thousands of transactions a day. A good maintenance process, however, should include at least a few elements.
- 1. Security monitoring. The team should know about new vulnerabilities regarding the components being used.
- 2. Regular dependency updates. It is much easier to update an application in small steps than to execute a multi-year version jump.
- 3. Technology version control. The framework, runtime, database, and operating system should not run long after official support has ended.
- 4. Automated testing. Without tests, every update becomes riskier. This is one of the reasons why tests are an investment not only in development quality but also in the later cost of system maintenance.
- 5. Post-deployment monitoring. Even if tests pass correctly, a regression may only appear in the production environment. It is worth observing, among other things: the number of errors, response times, resource consumption, operation of external integrations, and critical business processes.
- 6. A plan for major version updates. A major framework upgrade should not be a surprise. It is worth knowing in advance when support for the used technology ends.
- 7. Clear accountability. The worst answer to the question: “Who is responsible for updating this system?” is: “Actually, no one.” The maintenance process should have an owner. Organizing SLAs, priorities, and ticket response methods also helps here – we describe similar rules in the article on how process standardization and SLA affect service quality.
How often should you update the application?
There is no single frequency that is good for every project. However, you can adopt a simple rule: the more important the system, the shorter the time should be between detecting a significant problem and resolving it. A critical vulnerability actively exploited by attackers should not wait for the scheduled “quarterly maintenance.” A regular library update, on the other hand, can easily go through the standard process. This is why companies increasingly divide updates into several categories:
- emergency – critical vulnerabilities and actively exploited threats,
- security – security patches requiring rapid deployment,
- maintenance – regular patch and minor versions,
- planned upgrade – major changes to frameworks, databases, or runtimes.
Thanks to this, an update stops being a chaotic reaction to a problem. It becomes a standard element of product management.
How do you know when an application is heavily neglected?
There are several characteristic signals. The first is a situation where the team is afraid to perform any update. The second – when no one knows if there are automated tests in the project and how to run them. Further red flags are:
- a framework several major versions behind the current release,
- a lack of production updates for many months,
- an unsupported version of PHP, Node.js, Java, or .NET,
- a lack of knowledge about the application’s dependencies,
- dozens or hundreds of Dependabot alerts,
- a non-functioning CI/CD pipeline,
- no staging environment,
- no monitoring,
- deployments performed manually,
- documentation not updated for several years.
If several of these points occur simultaneously, a regular update may no longer be enough. The first step should then be a technical audit and determining which elements require immediate reaction and which can be modernized gradually.
Maintenance does not mean constantly rewriting the application
It is also worth dispelling the other extreme. Regular maintenance doesn’t mean you have to write the system from scratch every two years. On the contrary. Well-maintained applications require a full rewrite much less frequently. If we regularly: update technologies, refactor the most problematic fragments, develop tests, remove unused code, and guard architecture quality, the system can be developed for many years. The most expensive rewriting of an application from scratch is often not the result of a bad framework choice a few years earlier. It is the result of years of lacking maintenance.
In 2026, software must be treated like a living product
The era of applications that could be deployed to a server and left untouched for five years is essentially over. Today’s systems are too interconnected with the external ecosystem.
Dependencies change.
Operating systems change.
APIs change.
Browsers change.
Security requirements change.
User expectations change.
And above all – threats change.
That is why a lack of changes in the repository doesn’t mean the application stays in the same place. Technologically, it is constantly moving backwards. You don’t have to update everything immediately. You also don’t have to chase every new version of a framework the day after release. What is needed most is a controlled and regular maintenance process. Because minor updates performed every month are usually much safer and cheaper than trying to catch up on five years of technological changes the moment the system starts blocking the business.
The best moment to modernize a system is not when the application has just stopped working. It is best done while it is still working and we have the opportunity to plan changes without pressure. If your system hasn’t been updated in a long time, uses older technologies, its development is becoming increasingly expensive, or you are not sure what state the code and infrastructure are in, it is worth starting with an analysis of the current situation. The DevQube team can help with a technical audit, taking over an existing project, modernizing the application, and planning the process of its further development and maintenance. Contact DevQube and let’s check if your system needs a few updates, gradual modernization, or larger architectural changes.
