The Deferred Maintenance Trap

We got an interesting call a few weeks ago from a client we hadn't spoken to in a long time.

Back in 2016, we built them a custom application.

For a solid decade, it ran without issue, it was code doing exactly what it was supposed to do.

This year, it broke.

Whilst the code and business logic hadn’t changed, the technical landscape outside of the app had shifted significantly.

Old reliable

We often find that people think about buying custom software the same way they think about buying a car.

They want reliability, good mileage, and to be a bit cheeky by skipping that 12-month service. In reality sometimes we want that for them too.

You might have bought a 1990’s Honda Civic for exactly this reason; if you change its tyres and top up the oil regularly enough, it’ll run for decades. The roads aren’t going anywhere and the physics of combustion aren’t going to change.

Unfortunately, contemporary software doesn’t work like that, as you don't own the environment.

You still have the reliable Civic, but now every three years, the transport agency informs you that your seatbelts don’t meet safety standards and are no longer fit for purpose.

Beyond that, most of the mechanics in town are starting to only service EVs, because that’s where the market is headed and it's what their customers need and expect.

But your Civic is still reliable, you can push that service out for yet another six months.

The rules of the road

Apple’s current rollout of "Liquid Glass" styling is a perfect example of how, if you're not intentional, things will catch up with you.

When iOS 26 was introduced last year new design paradigms and glassmorphic UI were applied to standard app elements. For a lot of older, custom-built interfaces, this broke the app layout completely. There were contrast issues, weird overlaps, broken navigation bars, and buttons that just disappeared.

Apple provided a temporary escape hatch to make the transition easier. They introduced a flag called UIDesignRequiresCompatibility; basically what this meant was if you need to get a build out you could opt out of Liquid Glass and keep your salmon valour seats.

With the recent WWDC and the launch of iOS 27, that escape hatch is closing. Apple announced in June 2026 that the flag will be removed from the system by April 2027, forcing Liquid Glass adoption with each new build of your application.

This is standard for OS providers, not just Apple: they know how to get the most out of their environments and want people using them properly. The trade off to getting all of the iOS benefits you know and love, is that your apps must be built using the latest software development kit (SDK).

The need for speed

Now, just because Apple is making this change doesn’t mean you will feel the pain tomorrow. You could choose to hit pause again. The change will only impact you if you need to run a new build. Basically you can keep driving your Civic as long as the engine is running smoothly. But this comes with its own consequences, a running engine doesn’t guarantee that you’ll pass your WOF.

Let's say you get a bit of engine noise, a bug that disrupts your invoicing flow. It's business-critical, requires a small fix, and it's needed yesterday.

If you try to push that tiny, routine bug fix update, it will be blocked. To get that fix out, you have to rebuild your UI. Updating the UI exposes older libraries that no longer work with the new SDK. Swapping out those libraries breaks your backend integration, which now requires a completely new API structure.

What should have, or could have been a day of routine maintenance spread over the years has compounded into a massive, expensive rescue mission that might take months to execute.

Intentional pausing works remarkably well, right up until the moment it doesn’t.

Check your blindspots

Having said all this, we appreciate that budgets aren't infinite, we know there are competing priorities, and we're not advocating for chasing every new framework that drops. Intentional pausing is a completely rational business decision. You accept the technical debt, save money in the short term, and focus your resources elsewhere.

The danger is when the decision stops being active. When "we chose to hold" becomes "we never got around to it.” These are the kinds of blind spots that we sometimes see our customers trip over. Technical debt itself isn’t necessarily the issue here, it's the loss of purposeful decision making that starts the deferred maintenance clock ticking.

Ultimately, as a software development partner, it's sometimes our job to tell you that the rattling that you’ve been drowning out by cranking up the radio… that really needs to be fixed now.

Just as staying put has trade-offs, we also appreciate that the bleeding edge carries a tax of time and money. The important thing from our perspective is not a value judgement on what approach is right or wrong. What matters is that you’re the person in the room who knows which road you're on, why you chose it, how long you've been on it, and what hazards might now be on the road ahead.

Stay in the driver's seat

This article isn’t a sales pitch to get you to sign a statement of work for support and maintenance. We don't want you feeling like you have to update your software weekly because Apple made a change to their environment.

Choosing to extract value from your current build without touching it is fine. But if you hit pause, you need to do so with your eyes wide open. You need to be aware of when your digital Warrant of Fitness is going to expire.

One of the best ways to stay in the driver's seat is to treat your software like any other asset that needs repair and maintenance budgeted for it every year. That means putting the technical debt on the books, being aware of it, and accruing for the day you know is coming. The bill coming due doesn't have to be a crisis, so long as you've been planning for it.

As for that customer whose app broke after ten years? We got it running in three hours. But they were lucky; it wasn’t a cracked head gasket.

In software sometimes the seatbelts really do need to be replaced. We just want to make sure you still have a car to sit in when they do.