A large share of organizations that suffered a data breach traced it to a known vulnerability that already had a patch available. The fix existed. A version number had shipped. Nobody applied it. That single statistic, surfaced repeatedly in breach post-mortems, is the quietest and most expensive truth in software: the danger is rarely some exotic zero-day. It is the update you didn't get around to installing.
Launch feels like a finish line. The site goes live, the team exhales, the invoice clears. But the code you shipped started aging the moment it went into production. Below is what actually happens in the months after, and why the part nobody budgets for tends to be the part that bites.
You don't write most of your software, and that's the problem
A modern web app is mostly other people's code. Most of a typical application is open-source dependencies, frameworks, libraries, and the libraries those libraries pull in. The 2024 State of the Software Supply Chain data found that 86% of enterprise codebases contained at least one known-vulnerable open-source component, and that more than nine in ten codebases were carrying components several years out of date.
Those dependencies don't sit still. They ship security patches, fix bugs, and occasionally make breaking changes. Skip the updates for a year and you're not running stable, finished software, you're running a museum exhibit that attackers already have the map to. Around 14,000 malicious packages were discovered in popular registries by the end of 2024 alone, a sharp jump year over year. The supply chain you inherited at launch keeps moving whether you watch it or not.
The clock runs faster than you think
Here's the uncomfortable timing. The median time for attackers to exploit a newly disclosed vulnerability collapsed to roughly one day by 2024. The average organization, meanwhile, takes around 58 days to remediate, and for some industries critical fixes stretch past 130 days. Read those two numbers together: attackers move in 24 hours, defenders in two months. That window is where breaches live, and it widens every day a system goes untended.
It isn't only security. Browsers update every few weeks. Mobile operating systems ship yearly and deprecate APIs. Payment providers rotate requirements. A checkout flow that worked perfectly at launch can quietly break because Safari changed how it handles a cookie, not because anyone touched your code. Software decays not because it was built badly, but because the world around it keeps changing.
What neglect actually costs
The bill for ignoring all this is not theoretical. A single hour of IT downtime is expensive for mid-size and large enterprises, and for many the cost runs into the millions. Most of those outages aren't dramatic attacks. They're expired certificates, an unpatched library that finally gave way, a dependency conflict nobody was watching.
The cruel math is that maintenance is cheap and neglect is expensive, but maintenance is visible on the invoice and neglect is invisible until it isn't. Skipping a few hours of patching each month feels like a saving right up until the morning the checkout goes down during a campaign.
How we think about it at True Dev
We've been building software since 1997, long enough to watch plenty of "finished" projects quietly rot for lack of anyone tending them. So we treat a launch as the start of a relationship, not the end of an engagement. Dependencies get updated on a cadence. Security advisories get triaged before they become incidents. When a browser or OS shifts the ground, we adjust before users notice.
Software is a living thing. It needs feeding. The cheapest version of that is steady, boring, ongoing care, the kind that means you never get the 2 a.m. phone call. If you're planning something new, talk to us about starting a project the right way, and have a look at how we structure ongoing services so launch day is the beginning of a long, uneventful life, not a countdown to the first outage.
