If You Change, I'll Find Something That Doesn't

31 Jan 2026

(A followup to If You Change, I'm Leaving)

When was the last time you updated a piece of software and it got better?

Or got an "important update from Foo.com" email about one of your SaaS suppliers, and the change was positive?

In both my work and personal capacities, I do still update for security. Although, with the increase in first-party malware1 and supply chain attacks2, this is less clear-cut than it used to be.

But I'm including both SaaS and local software - to the extent that there's even a difference any more - when I say that my expectation after an update is that it will be:

  • slower
  • more intrusive
  • more expensive, and/or
  • more ridden with unhelpful AI

To some extent all I can do is suck it up. It's not like turning updates off for long is even possible - some software simply doesn't permit it, and a lot of the rest simply stops working or displays a doorslam "upgrade now". Almost nothing remains compatible with cloud servers that I can't prevent from changing month-by-month3.

But it's a constant drain on my productivity. Life - and particularly programming - is learning, which is great. But I'd rather be learning something more useful than how to fix my workflow in a UX that's changed, for no reason, again.

How To Escape

Self-hosting and free software has always been the way out of this churn4. This just got a lot easier, because software just got a lot cheaper5, and once it's in your repo, it can't change out from under you.

One of our SaaS dependencies (a CMS) just changed their pricing structure, resulting in a 10x (!) increase for us6. A bit of refactoring on our side would have reduced that to 4x - but if I'm going to have to do that refactoring anyway, I can cut deeper.

I evaluated a few paths:

  • A) Suck it up, pay the money. This costs money (but then so does software development), but also leaves us exposed. Even if you aren't mitigating in advance, if a risk actually eventuates it's pretty dumb to not then take action to make sure it can't do exactly the same thing again.
  • B) Find a new supplier, following the logic in If You Change, I’m Leaving. DatoCMS is really good, it's built in the EU7, and we're already familiar with it. But it's still a cloud dependency.
  • C) Self-host an existing open-source tool like Payload, Directus, or Strapi. Good direction-of-travel, but it's a heavy lift, starting with evaluation, then deployment, customisation, and re-learning workflows. The weight comes from having a lot more features than we actually need. (We did this when Papertrail was bought out, moving to Signoz.)
  • D) Screw it, just write exactly what we need, and no more.

The advantage of (D) is that I can very tightly constrain the feature set and blast radius, and match it precisely to our existing workflows. Features the software doesn't have, the users don't have to learn, and the developers don't have to maintain. Years ago it still would have been too much work to justify, but now, it's not far off from:

This project uses $OLD_CMS. Let's migrate it to use static json files committed into the repository instead. Preserve existing interfaces as much as possible. Image and audio assets should be committed into the repo; videos should be uploaded to S3 and referenced there.

Followed by:

Projects at $DIR_1, $DIR_2, and $DIR_3 have static json files (the result of migrating away from a CMS). Let's build a local editor using typescript+vite that uses the File System API to allow editing those json files directly in the repo.

(This is a simplification; it was still a day's work to update half a dozen codebases, and another day of review and testing. Easily ROI in the first year even at the old pricing.)

Don't just vendor your dependencies. Now you can vendor your suppliers8.

Footnotes

  1. Eg https://thehackernews.com/2025/12/a-browser-extension-risk-guide-after.html - or, more cynically, Windows Recall and friends. ↩

  2. Eg this evolution of Shai-Hulud ↩

  3. API versioning, it appears, is a lost art. ↩

  4. Provided, of course, that you vendor - or cache - your dependencies. ↩

  5. I am, broadly, an AI cynic. Its art is Terrible on many levels, it still can't drive a car, and AGI isn't coming. But holy crap, for simple, well-trodden-path software, given a good spec and a testing feedback loop, it flies. ↩

  6. To be clear, I bear no ill will. They gave us lots of warning, they were nice about it, and we were on a seven year old grandfathered plan. It's just business. ↩

  7. Though still hosted on AWS. ↩

  8. Possibly while wearing this t-shirt. ↩