It's built. It works. So why am I still paying for it?

Fair question. We get asked it a lot.

You commission some software. We build it. It goes live, it does the job, and everyone is happy. Then we tell you that there's an ongoing support and maintenance contract on top, billed separately, for as long as the thing is running.

If the software works, what exactly is the work?

First, the exception

There is one kind of software that doesn't need any of this. If your code is on a little chip inside a microwave, and that microwave never talks to the outside world, you can build it, ship it and forget about it. Nobody can get at it.

Almost nothing we build is like that. Web apps, customer portals, APIs, anything with a login page: all of it is connected to the internet. And the moment something is on the internet, it is being poked at, constantly, by people and (increasingly) machines looking for a way in.

That's what the maintenance is for. It's not about adding features. It's about security.

Your software isn't just your software

Here's the bit that surprises people. The code we write for you is a small layer sitting on top of a very large pile of other people's code.

There's the operating system the server runs on. The web server that handles requests. The database that holds your data. The programming language itself. The framework we build on. And then dozens, often hundreds, of smaller libraries that do things like send emails, generate PDFs, handle payments and check passwords.

All of that was written by other people, and all of it has bugs nobody has found yet. That's not a criticism, it's just how software is. Some of those bugs turn out to be security holes.

When someone finds one, it gets fixed and announced. That announcement is both good news and bad news. Good, because there's now a fix. Bad, because every attacker in the world now knows exactly where the hole is, and they start scanning the internet for anyone who hasn't applied it. That scanning starts within hours.

So the job is simple to describe and endless in practice: keep every layer of that pile up to date, so that when a hole is announced, you're not one of the people still standing in it.

What happens when you don't

A few examples. Each one links to an article that explains it properly, but the short versions are frightening enough.

Heartbleed (2014). A bug in the library that most of the internet uses to encrypt traffic. It sat there unnoticed for two years. It let anyone read passwords, private keys and other secrets straight out of a server's memory, and it left no trace. Roughly half a million websites were affected.

Log4Shell (2021). A flaw in a logging library that lives inside an enormous number of systems. Sending a specially crafted bit of text, into a search box or a username field, was enough to take complete control of the server. It scored 10 out of 10 on the severity scale. Our favourite grim detail: some attackers broke in through it and then patched the hole behind them, so the owner would think they were safe.

The Equifax breach (2017). The fix for the flaw was published in March. Equifax hadn't applied it by May, attackers walked in, and the personal details of 147 million people went out the door. The company ended up paying over $700 million in settlements. The patch had been sitting there for two months.

WannaCry (2017). Ransomware that spread itself across the world in a day, hit a third of NHS trusts, and cancelled thousands of appointments. Microsoft had released the fix two months earlier. Every machine that got hit was one that hadn't been updated.

Notice the pattern. In every case the fix existed. The damage was done to people who hadn't applied it yet.

Then AI turned up

AI has changed this picture in two directions at once.

The blessing: the work of keeping things up to date has got quicker and cheaper. A lot of the grunt work of updating a library, dealing with whatever it changed and re-running the checks is now something we can hand to AI tools and supervise, rather than do by hand. That's real, and it's part of why we can offer maintenance at the price we do.

The curse: AI is also very, very good at finding vulnerabilities. In May 2026 Google confirmed the first attack in the wild using an exploit that had been developed with AI. Around the same time, one security firm reported that its AI system had found over 14,000 previously unknown vulnerabilities across open source software. That's the pile of unfound bugs we mentioned above being found, at scale, by machines.

Which means holes get discovered faster, they get weaponised faster, and the gap between "fix announced" and "attackers exploiting it" keeps shrinking. If anything, staying current matters more now than it did five years ago, not less.

Why you can't just "apply the updates"

There's a catch. Updating a library or a database or a language version can break things. Behaviour changes, edge cases shift, something that used to work quietly stops working.

If you can't tell whether an update has broken your system, you're stuck. Either you don't update (and stay exposed) or you update and hope (and find out from your customers).

The way out is the boring, unglamorous engineering practice we bang on about constantly: a proper automated test suite that exercises the whole system, run before anything goes live. With that in place, an update is a routine job. Apply it, run the tests, check nothing has regressed, ship it. Without it, every update is a gamble.

This is why we build every project with tests from day one. It's not just about catching bugs while we're building. It's what makes the next ten years of updates safe.

What this means for a Lamp build

Every project we build comes with an ongoing support and maintenance contract, billed separately from the build. It covers keeping the whole stack current, from the operating system up to the libraries in your code, and responding quickly when something serious lands.

It's not the exciting part. Nobody launches a product and celebrates the patching schedule. But it's the part that keeps you out of the news for the wrong reasons.

If you're running something that was built a while ago and you're not sure when it was last updated, that's worth finding out. Happy to have a look.