iHomePage started in 2017 as a drag-and-drop website builder. It has been rewritten several times since, as the technology underneath it got good enough to justify the rewrite. The site you're reading this on runs on it. And the honest part, the part I'd rather not lead with: it took the better part of a decade to work out what the product *isn't*. Nine years to get the positioning sharp. That's either embarrassing or just how it goes, and I've stopped being sure which.
Here's the conclusion up front, because I hate articles that make you scroll for the payoff. The useful distinction in software isn't old versus new, or simple versus clever. It's whether a thing was built to be shipped or built to be lived with. Software built to be shipped optimises for the moment of delivery: the release notes, the demo, the migration guide nobody reads. Software built to be lived with optimises for the nine-hundredth day, when you are mid-task, have forgotten the thing exists, and need it to behave exactly as it did on day one. Those two targets pull in opposite directions far more often than anyone admits, and almost every incentive in the industry points at the first one.
I want to argue for the second. I also want to be fair about what it costs, because the strongest objection to patient software is a serious one and I'd rather make it myself than have it made at me.
The receiving end
The clearest way to see what "built to be shipped" produces is to read a vendor's own bug list.
On 14 October 2025, Microsoft released KB5066835 for Windows 11. Its own support page lists four known issues in that update. One of them: "USB devices, such as keyboards and mice, do not function in the Windows Recovery Environment (WinRE)." Another: "IIS websites might fail to load" — server applications relying on HTTP.sys losing incoming connections, and the page is explicit that "This includes websites hosted on http://localhost/ and other IIS connections." Microsoft's suggested step is to check for updates and restart the device, "even if no updates are installed."
So: one update broke the recovery environment you would need if an update went wrong, and separately broke localhost, which is to say it broke the machines of people who develop software for a living. The USB-in-recovery defect needed an out-of-band fix, KB5070773, six days later. The missing lock-screen password icon from the same update wasn't fixed until KB5074105 in late January 2026, more than three months out.
And the date matters. 14 October 2025 was the day Windows 10 reached end of support — the day a very large number of people were being told that moving to this was now the only responsible option.
A year later the pattern hasn't changed shape. Microsoft's own release-health page for Windows 11 24H2 carried, through September and October 2026, an issue titled "Applications which require AC-3 audio decoding might close unexpectedly," caused by KB5124010 on 22 September 2026. Microsoft's description of who got hit is the part I keep rereading: the affected component "is most commonly used in legacy applications that still rely on Windows built-in audio decoding," whereas "many modern applications... include their own audio decoding components."
Read that again as a sentence about incentives. The applications that trusted the platform to keep its promises broke. The applications that gave up on the platform and shipped their own copy of everything were fine. That is a tax on patience, levied by the platform, and stated plainly by the platform.
There is a tidier version of this point. Microsoft ships a mechanism called Known Issue Rollback, whose entire purpose is to undo Microsoft's own updates via Group Policy. It's how the domain-trust regression from the September 2026 updates was handled. I don't think that's incompetence. I think it's an institution being realistic about itself: once you ship continuously to a billion machines, "our updates break things" stops being an incident and becomes a category that needs tooling.
The sharpest single case I found isn't a PC at all. US National Highway Traffic Safety Administration campaign 25V710000, report received 17 October 2025, covers 2023–2025 Jeep Wrangler 4xe. NHTSA's own summary: "A software error in an over-the-air update may cause a loss of drive power." Consequence, in their words: "Loss of drive power increases the risk of a crash." An update, delivered over the air, that stopped the thing while people were using it. The remedy is a dealer visit.
Deferred cost
I wrote up a smaller version of this earlier in the year, from the user's side rather than the builder's: Claude Desktop on Windows closing itself overnight during a background auto-update and then refusing to reopen, behind a system error message that was wrong about the cause. Chasing that one took me from "another program is using this file" down to kernel object reference counting, and the conclusion I landed on there is the same one I'd defend here: rebooting to keep an application working was never a real fix; it's just deferred cost.
My machine doesn't reboot unless something forces it. That's deliberate — a desk full of terminals, editors, background services and long-running SSH sessions is how I work, and tearing that down costs me real time to rebuild. So I'm not a neutral observer. But I'd make the argument even if restarts were free, because the design assumption is the problem, not the inconvenience. Software that takes it as given that it may restart your world whenever its own release schedule requires it has decided that its convenience outranks your continuity. Everything downstream of that decision — the overnight self-close, the dialog that lies about why, the reboot ritual that "fixes" it — follows from one line of thinking about whose time is cheap.
People have been arguing this for twenty years
I'm not claiming any of this is new. It's worth knowing who said it first, partly out of honesty and partly because the good versions of the argument are narrower and more useful than the slogan version.
Dan Bricklin wrote "Software That Lasts 200 Years" in July 2004. His frame is that some software has become infrastructure — he calls it "Societal Infrastructure Software," the software that "keeps our societal records, controls and monitors our physical infrastructure (from traffic lights to generating plants)" — and that the companies producing it are structurally incapable of treating it that way. His indictment is specific: "New revenue comes from selling to existing customers, with each new version needing to give existing users a reason to replace the old product," producing what he calls, twice, "a culture of obsolescence." His single best number is an accounting one: software is typically depreciated over three to five years, "10 at most," against 27.5 years for residential rental property and sixty-plus for water mains and brick walls. He also notes, which is the part people skip, that services-based open source has the same disease.
Bricklin scoped his own argument carefully — "Remember, this is only for one part of the software world" — and I'd rather honour that than stretch it. Not everything should last 200 years. A marketing landing page should not.
The best existing proof that the long promise is keepable is SQLite. Its own long-term support page states: "The intent of the developers is to support SQLite through the year 2050." Not a roadmap, a stated intent twenty-five years out. And the promise that actually does the work: "the developers also promise to keep the SQLite C-language API and on-disk format fully backwards compatible," such that "Database files created today will be readable and writable by future versions of SQLite decades in the future." That is a vendor committing not to its features but to its interface and its file format — the two things a user's decade actually rests on.
The Linux kernel's version of the same move is better known and more instructive. Linus Torvalds, on the kernel mailing list in November 2010: "The rule is simply 'we don't break user-space'." And, in the same message, the bit that closes the usual escape hatch: "Even if the breakage is totally incidental, that doesn't help the user. It's still breakage." He'd answered "Never" in 2006 when asked when userspace could be broken, and in 2012 restated it in capitals at a maintainer who argued the bug was in PulseAudio rather than the kernel.
Here's the nuance that makes it real rather than inspirational: in 2021 Torvalds clarified that the regression policy covers the binary interface specifically — not source-level or build-time compatibility. The famous absolute promise applies to a deliberately small surface. That's why it's survived thirty years. A promise broad enough to cover everything would have been broken in its first month and then quietly dropped. Patient software works by picking a narrow surface and being genuinely absolute about it, not by being careful about everything.
Permacomputing comes at it from a different direction — ecological rather than commercial. Ville-Matias Heikkilä's essay, published June 2020, is where the term got its current meaning, and his line about chips is the one that sticks: because fabrication "requires large amounts of energy, highly refined machinery and poisonous substances," the resulting microchips "should be treasured like gems or rare exotic spices." His prescription, four words: "Instead of planned obsolescence, there should be planned longevity." The community wiki that grew out of it lists a principle called "Build On Solid Ground" — rely on mature, well-documented standards and open formats so that your data stays readable even if your software disappears. Which is the SQLite promise, restated as ethics rather than as a support page.
The rest of the canon I'd point at with a caveat. Nikita Prokopov's "Software disenchantment," September 2018, is the most-shared version of the complaint, and his numbers were good: a text editor spending 16ms on a keystroke while a 3D game pushes hundreds of thousands of polygons in the same budget; Windows 95 at 30MB against Windows 10 at 4GB, "133 times as big"; Google Keyboard at 150MB to draw thirty keys. The caveat is that he has since substantially revised the diagnosis. In March 2026 he wrote about why Claude Desktop is an Electron app and concluded, against his own earlier framing, "The web is not the problem here! It's a choice to be bad... The real problem is a lack of care." I think he's right the second time, and it's inconvenient for anyone who wanted this to be an argument about technology choices. It isn't. There's a separate case to make about picking deliberately boring tools — Dan McKinley's "Choose Boring Technology" from 2015, with its budget of roughly three innovation tokens per company, is still the best statement of it — and I've written that one up separately. It's a different essay because it answers a different question. You can build something unlivable out of entirely boring parts.
What actually survives, according to people who have the receipts
The applications that have genuinely lasted are less romantic than the slogan wants them to be.
BBEdit was first released in April 1992, as a free proof-of-concept editor for an experimental Pascal compiler. Bare Bones shipped BBEdit 16.0 on 21 May 2026, with Rich Siegel — still the lead developer, thirty-four years in — quoted in the company's own press release saying "BBEdit 16 is the feature release I've wanted to make for a long time." The current build as I write is 16.0.3, and its release notes say it "contains only changes to address reported issues. There are no feature additions or changes in this update." The copyright line on their site reads 1992–2026. That range is the whole argument, and it was earned by shipping bug-fix-only releases for decades, not by refusing to change.
Sublime Text reached 1.0 in January 2008. Version 3 shipped in September 2017 after a beta that began in January 2013 — a four-and-a-half-year beta. Version 4 landed in May 2021 and the current download is build 4215, dated 25 September 2026: five and a half years into a major version, still shipping builds, no version 5. For users that cadence reads as stability. For anyone waiting on a specific fix it reads as neglect, and both readings are correct.
IRC is the honest case. Jarkko Oikarinen wrote it in August 1988; RFC 1459 dates from May 1993, and the later revisions were, as the record notes, not widely adopted — the 1993 document is what the ecosystem still runs on. Peak usage was around six million simultaneous users in 2001. As of 2026 the top hundred networks serve somewhere over 162,000 users at a time. That's a protocol down roughly 97% from its peak and still perfectly functional thirty-eight years on. Longevity without growth. Any argument for patient software has to be willing to call that a success, and if it isn't, it's an argument about market share wearing a different hat.
Winamp is the cautionary one, and it cuts against sentiment. First released April 1997; the last official stable desktop release is 5.9.2, from April 2023. In September 2024 its current owners published the source on GitHub under a bespoke licence containing a no-forking clause, on a platform built entirely around forking. Within days the licence was amended. Within weeks the repository was deleted outright, after it emerged that it contained third-party proprietary code the company had no clear right to publish — including server code it had already sold to someone else. It had been forked more than 2,600 times before the deletion, so the bits survived. An attempt to hand a twenty-seven-year-old program to posterity failed because nobody at the company knew what was inside their own codebase. The code hadn't rotted. The provenance had.
The community discussion on this is better than the blog-post discussion, and more self-critical. In a 2024 "Ask HN" thread on building software to last, a commenter posting as tomohawk described thirty-year-old UNIX software of his own still in use, "pretty much unmodified," now on Linux, "It can still be built today, as dependencies are minimal," and asked the question I'd put on a wall: "Will your build system just work in 30 years? What about your operating system?" His conclusion from being hired back to modernise it: "Modern practices assume easy connectivity to get resources from places not under your control. To achieve longevity, you need to bring all of those resources under your control."
And then the comment that should be read aloud at anyone making my argument. In a 2016 thread on the oldest code people still have running, a commenter posting as nostrademons put the uncomfortable law plainly: "The smaller the userbase, the more likely the code is to remain in service forever." He had the figures on himself — about 3% of the code he wrote during his years at Google was still in production when he left, and by his own rule, "it's silly stuff that nobody ever sees." Longevity correlates with not mattering very much. Any honest case for durable software has to sit with that.
My favourite complication came from a 2020 thread asking which "finished" software people use. Someone nominated Windows Notepad. Someone else pointed out it isn't finished — it has had features added for years. And then the original commenter supplied the better objection himself: Notepad is a thin wrapper around the Edit common control, "which is still being changed and improved with every Windows update." The software that *feels* finished is usually riding on something that never stopped moving. Stillness at the top of the stack is frequently purchased by churn further down, and you don't get to claim the first while ignoring the second.
Where the other side is strongest
Now the objection, and it's not close to frivolous. Software that nobody touches is a security liability, and the data on this got worse recently rather than better.
The 2026 Verizon Data Breach Investigations Report, covering October 2024 through November 2025 and drawing on more than 31,000 incidents, states: "The exploitation of vulnerabilities is the most prominent initial access vector in our dataset this year, reaching the height of 31%, up from 20% last year, which represents a 55% increase in this vector." Credential abuse, the previous leader, is down to 13%. Exploiting things that were already known to be broken is now the single most common way in.
The remediation figures are the part that should trouble anyone who likes my argument. "Only 26% of critical vulnerabilities—defined as being in the CISA KEV catalog—were fully remediated by organizations in 2025, a drop from the previous year's 38%." Median time to full resolution rose to 43 days. And from the report's survival analysis across more than a billion vulnerability detection records: "By Day 7... somewhere between 60% and 70% of KEV vulnerabilities remain open regardless of year, volume or organizational maturity. This first-week rate barely moved despite three years of additional process development, tooling investment and mandate pressure."
Google's M-Trends 2026, published in March, puts the mean time-to-exploit at an estimated −7 days: "meaning exploitation is routinely occurring before a patch is even released." Negative. The window in which being slightly behind is survivable has closed.
The CISA Known Exploited Vulnerabilities catalog, version 2026.10.23, lists 1,755 entries. 558 of them — 31.8% — have CVE identifiers predating 2020. Bugs disclosed and patched six or more years ago, still under active exploitation now. A joint advisory from nine countries' agencies on 8 October 2026 lists successfully exploited CVEs including one from the 2014 Shellshock family and an ISC BIND bug from 2015 — patches eleven and twelve years old, being used this month.
And the single most damaging fact against me. In February 2026 CISA issued Emergency Directive 26-03 — the only emergency directive of the year — over exploitation of Cisco SD-WAN systems, giving federal agencies two days to act and calling the activity "an imminent threat to federal networks." Attackers chained a genuine zero-day authentication bypass with CVE-2022-20775 to escalate to root. The Cisco advisory for that second one is dated "First Published: 2022 September 28" and states "There are no workarounds." The fix had been available for three years and four months. The 2026 zero-day was only *useful* because a 2022 patch hadn't been applied.
A year after Windows 10 stopped being serviced, StatCounter still put it at roughly a quarter of worldwide desktop Windows. Those machines aren't patient. They're just old.
So: patient does not mean untouched, and I won't pretend otherwise. If your idea of durability is a box in the corner on its original image, you're not making my argument, you're making the attackers'.
The thing both sides keep missing
Here's where it gets interesting, and where I think the usual framing is wrong on both ends.
The update channel is also an attack surface, and over the last two years it has been the productive one.
On 8 September 2025 a maintainer of several extremely widely used npm packages was phished through a lookalike domain registered three days earlier, which proxied the real login and captured a live one-time code. Eighteen packages were backdoored, with combined weekly downloads in the billions. They were live for roughly two hours.
On 31 March 2026, malicious versions of axios — a package with over 100 million weekly downloads — were published at 00:21 and 01:00 UTC and removed around 03:30. Two to three hours. The detail that matters: the project had already adopted OIDC trusted publishing, the recommended hardening. The attacker hijacked the maintainer's account and published manually with a stolen token, going around it. There is no matching commit, tag or release in the repository.
And the purest case, because nothing was published at all. On 14 March 2025, attackers compromised a bot's access token for the tj-actions/changed-files GitHub Action and retargeted most of its version tags to a single malicious commit. Workflows that pinned by tag, and changed nothing whatsoever, started running attacker code. Over 23,000 repositories used it. The payload dumped memory and printed secrets into workflow logs, which on public repositories anyone can read. No publish, no version bump, no user action. The mutable reference was the entire attack.
Notice the exposure windows: forty minutes to three hours, consistently. Longer than a CI job. Shorter than any human's reaction time. "We detect these fast" is no protection at all when the consumer is a pipeline that updates on its own.
Be careful what you take from this, because it's easy to overclaim. The common factor in every one of these incidents is a compromised publishing credential, not update frequency. The answer is not updating less. It's lockfiles, pinned hashes, declining to execute install scripts, and a deliberate gap between a version existing and a version being adopted.
Which is, interestingly, exactly where the registry went. After the September 2025 compromise, npm narrowed publishing to mandatory-2FA local publishing, short-lived granular tokens, or trusted publishing; classic tokens were revoked outright in December 2025. And the newest mechanism is a token scope described as "Read and write (stage only)" — one that "lets the token stage new versions for a maintainer to review and promote, but not publish them directly."
A human review gate. The fix for an update channel that moved too fast turned out to be deliberate slowness, introduced on purpose, at the point of publishing. That's not a concession to nostalgia. It's the same argument I'm making, arrived at independently by people whose entire job is to make updates arrive quickly.
When the vendor leaves
The failure mode I find least discussed is the one where nothing breaks and nothing gets exploited — the software simply stops being there.
MinIO is the cleanest example because every step has a date. In October 2025 its maintainers stopped publishing container images; the co-founder's own words on the GitHub issue were "This project is a source only distribution now, if you want to build containers you need to build them yourselves" — a change that landed while a CVE was open, so users were told to build from source to get a security fix. In December 2025 the README gained the line "This project is currently under maintenance and is not accepting new changes," with existing issues and pull requests no longer actively reviewed. By early 2026 it read "THIS REPOSITORY IS NO LONGER MAINTAINED." The repository was archived in April 2026. The licence never changed. They stranded users by withdrawing artifacts and attention instead, which is both entirely permissible and completely effective.
Amazon closed Mechanical Turk on 30 September 2026, after twenty-one years. There is no AWS blog post about it; the announcement is a notice on the site. No replacement is named.
Belkin shut down the Wemo cloud on 31 January 2026, after which, in the company's own words, "New setup or reconfiguration via the Wemo app or HomeKit will not be possible after this date." Refunds were offered — "If your Wemo product is still under warranty." Which is to say the people who had lived with the product longest, the ones whose loyalty the whole category depends on, got nothing. That inversion is not an oversight. It's a straightforward reading of who is still worth something to the company.
Skype was retired on 5 May 2025 and the long tail ran for another year: numbers terminated, caller ID switched off in February 2026, bundled minutes removed, subscriptions ended, and the data export portal closing in June 2026. The sharpest clause, from Microsoft's own support page, is that users who were not active on Skype or Teams Free between December 2024 and February 2025 may lose their chat and call history outright — a retroactive activity test applied to data people had already stored, years earlier, under different terms.
One pattern worth naming: across every one of these shutdowns, not one vendor published a user count in its own sunset notice. Every scale figure available comes from the press. Companies that strand people do not say how many.
The part about my own nine years
I don't get to make this argument from a clean position, so let me not pretend to.
A product that started as a drag-and-drop builder in 2017, got rewritten several times, and only arrived at a sharp sense of what it isn't in 2026 is not an advertisement for patience. Nine years with multiple rewrites is churn. If a vendor did that to me I'd have written about it the way I wrote about the auto-update that closed itself overnight.
Two things I'd say in my own defence, and only two.
The first is a distinction I'd defend hard: a rewrite you choose is not the same thing as a restart someone else schedules for you. The cost of a rewrite lands on the people who decided to do it. The cost of a forced update lands on someone who was in the middle of something. Those are different moral objects even when the code churn is identical, and most of what makes software unlivable is not change but change you didn't get to time.
The second is that the decade wasn't spent on the parts I'd call infrastructure. It was spent working out what the thing was for — and the useful discovery turned out to be subtractive. Most of those nine years were spent finding out what to stop building. If the positioning is sharper now, it's not because something clever got added. It's because a long list of things that looked like features got removed from the plan, and every one of them was a thing that would have needed tending forever.
That's the connection I'd draw, and it's the only kind of self-defence I'd offer: the easiest way to make software unlivable is to give it more surfaces that need attention. Not bad code. Just more of it, each piece plausible on its own, each one a thing that can break on a Tuesday in 2031.
What I'd actually do
If you are building something you intend to still be running in ten years, in rough order of how much they matter:
- Pick one narrow promise and keep it absolutely. Not "we care about compatibility." One named surface — a file format, a wire protocol, an API — that you commit to in writing and never break. SQLite promises its C API and on-disk format. Linux promises the binary interface and nothing wider. The narrowness is what makes the promise survivable.
- Never close a running process to update it. Download, verify, stage, and wait. The moment of application belongs to the user, not to your release calendar. This is the single most common way software tells its users their time is worthless.
- Separate security patching from everything else, so the user never has to choose between the two. A great deal of refusal-to-update is really refusal-to-accept-the-redesign that the security fix is bundled with. If you ship those together, you have made declining your patches rational.
- Make the data outlive the program. Open, documented, boring formats, readable with tools you didn't write. The test is whether a user could reconstruct their work if your company disappeared tomorrow, and you should assume it will.
- Own your build inputs. Not for purity — because, as that HN commenter put it, modern practice assumes connectivity to resources outside your control. If a dependency can vanish, your ability to ship a fix in 2034 depends on someone else's hosting bill.
- Count every new surface as a permanent maintenance obligation, and subtract accordingly. A feature is not finished when it ships; it's finished when it's removed. Judging a decision by what it will cost to still support in year nine changes which features look attractive.
- Put the sunset terms in writing before you need them. Where the data export lives, how long it stays up, what happens to self-hosted installs. Every vendor above wrote those terms after deciding to leave, which is precisely when the user has the least leverage.
- Patch promptly anyway. All of the above is compatible with applying security updates fast, and none of it survives if you use "durability" as a word for neglect. The numbers in this piece are unambiguous: the exploitation of already-patched vulnerabilities is now the most common way into an organisation. Patience is about what you promise and when you disturb people, not about how long you sit on a fix.
After thirty years of this, the thing I notice isn't that durable software is hard to write. Plenty of thirty-year-old code runs fine. It's that nothing in the ordinary operation of a software business ever asks you to think about year nine, and so nobody does, and then the bill arrives as a dialog box at seven in the morning telling you something is using a file, which isn't even true.