A while back, a customer emailed one of our clients to ask if their online store was a scam.

Nothing was actually wrong with the store. People could still add things to the cart and check out. But every product photo had turned into a little broken-image icon, the gray box with the torn corner. To a first-time visitor, that looks like a site nobody is minding. The kind you do not hand your credit card to.

Here is the part that surprised the client. Nobody had touched the site. Not their team, not ours. The photos broke on their own, over a weekend, because of a piece of software the site quietly leaned on. Something a developer had plugged in years earlier, that everyone had long since forgotten was even there, decided to update itself one night and stopped getting along with the rest of the site.

That sounds like a freak accident. It is not. It is one of the most ordinary things that can happen to a website, and it is worth about five minutes of your time to understand why, because it is almost certainly true of your site too.

Your software is built from other people's parts

Think about how a car gets built. The car manufacturer whose badge is on the hood doesn't make every part of the vehicle. They make some of it and buy the rest from suppliers. The brakes, the headlights, the little motor that rolls your window down. It's completely normal, and it is how you get a good car at a sane price. Nobody is going to reinvent a window motor from scratch for every car.

Software gets built the same way. When we make you a website or an app, we write the parts that make it yours. But we are standing on a big pile of parts other people already built and shared. The piece that resizes your photos. The piece that emails your receipts. The piece that talks to your payment processor. Using those saves you a small fortune. You are not paying anyone to reinvent the thing that resizes an image.

Every one of those parts, though, is a small standing bet. A bet that it keeps working. A bet that whoever made it keeps fixing it. A bet that its next version does not pick a fight with the part next to it. Most of these bets pay off quietly for years and you never once think about them. The ones that do not tend to go wrong around 11pm on a Sunday, and they land on your bill as "emergency work."

So here is the question worth sitting with, if you are the one who owns the thing: what is the best possible outcome for one of those little parts your site depends on?

The best outcome is for the big, well-funded team to take it over

Most of the websites and apps we build sit on a toolkit called Laravel. It is the sturdy, well-supported foundation of our projects, made by a large team with real people and real money behind it. Think of it as the carmaker's own factory rather than a one-person supplier working out of a garage.

This week, Laravel took over image handling itself. Resizing photos, tidying them up so they load fast, that sort of thing. Until now, that job was usually done by an outside part, exactly the kind that broke my client's product photos. As of this week, it is built into the foundation and looked after by the same big team that maintains everything else.

On the surface, that is a shrug. Resizing a photo is not thrilling. But the good part is not what it does. It is who is now responsible for it.

Before, if that outside part changed, or the person who made it lost interest and wandered off, that became your problem to untangle and pay for. Now it is handled by the team you were already relying on for the important stuff, the same people you trust to keep your customers' logins and payments working. You were going to keep that foundation up to date anyway. This just comes along for the ride, instead of being one more separate thing quietly rotting in a corner until the day it doesn't.

Spread that across the years you will own your software and it adds up to real money. Every part that moves from "some outsider looks after it" to "the main team looks after it" is one fewer thing that can blindside you, and one fewer line on a bill with the word emergency in it.

What this actually means for you

You do not need to follow a single word of the technical detail to get the benefit. You need people building your software who reach for the sturdy, well-supported option instead of gluing in whatever fragile shortcut is nearest, and who bother to swap in the better option when it finally shows up.

That is the whole reason we build custom software on foundations like this and treat maintenance as prevention rather than repair. We have written before about how most "maintenance" plans do not really maintain much of anything, and about how trouble often rides in on code nobody chose or checked. This is the happy other side of both.

If you want one thing to ask whoever looks after your website, here it is: how many outside parts are we depending on, and are any of them no longer being looked after by anyone? You do not need to understand the answer in any depth. A calm, specific reply is a good sign. A long silence tells you something too.

My client's broken photos took an afternoon to track down and about ten minutes to fix once we found the cause. The expensive part was never the repair. It was the two quiet years before it, leaning on a part nobody was watching, where customer's perception of the site was degraded. A dull little update that hands one more of those to a team who will actually keep an eye on it is, as unglamorous as it sounds, one of the better things that happened to their website all year.