Talk to us

Blog · 31 October 2026 · Rob Sherwood

If Your Software Supplier Went Bust, What Would You Do?

Pick the one piece of software your business can't run without. Now imagine the company behind it stops trading tomorrow morning. Do you know where your data is, who controls your web address, and how you'd serve customers by lunchtime?

That's not a hypothetical for some GP surgeries this week, and the questions they're facing apply just as well to a shop, a wholesaler or a ten-person services firm.

What happened

Silicon Practice, which trades as Schappit Ltd, supplied websites and online tools to GP practices. It has gone into administration. The Register reports that the disruption affects "potentially hundreds of practices" across the UK and that some GP websites have gone offline completely.

West and North London Integrated Care Board told practices on 28 October that three things were no longer available to them or their patients: the FootFall online consultation system, the practice websites and a chatbot feature. Practices using FootFall were told to let patients know they couldn't submit online consultation requests and to offer other ways of getting clinical support.

According to The Register, NHS England has written to practices about it. The priorities it reports are preserving historical patient information, stopping the online consultation backlog from growing, finding ways for patients to get in touch, and considering whether the Information Commissioner's Office needs to be told. The article doesn't report a data breach. The worry is about getting at data and keeping a service running.

I'm not going to guess at why it happened, and I don't know any more than what's been reported. What interests me is the position it leaves customers in, because any business that buys software could end up in the same one.

Buying software isn't the mistake

Let's be clear about this first. Renting software from a specialist is usually the sensible choice. Nobody should build their own email system or accounts package. A GP surgery isn't daft for buying a website from a company that does them for a living.

The risk isn't that you rely on a supplier. It's that you rely on one without knowing what happens if it stops. That's a much smaller problem to fix, and it costs very little to look at while everything's still working.

Five things to check this week

None of this needs a developer. A cup of tea and a spreadsheet will do.

1. Write down what you rely on. List every system you'd miss within a day: website, booking, stock, invoicing, phones, email. Next to each, put the supplier, who has the admin login, and how long you could cope without it.

2. Try getting your data out. Not "check there's an export button". Actually press it, and open what comes out. Does it include everything, or only the customer names and none of the history? Could another system read it? Do this now, because an export feature is no use once the login page has gone. If you can schedule a regular export to somewhere you control, do that too.

3. Find out who owns your domain. If your supplier registered your web address on your behalf, it may be in their account rather than yours. Own the domain yourself and you can point it somewhere else in an afternoon, so customers still find you even if the site behind it has to be rebuilt. Look it up today, and if the registered owner isn't you, ask for it to be moved.

4. Read the contract for the boring bits. What does it say about getting your data back when the service ends? Who owns anything built specially for you? If a system is truly critical, ask about source code escrow, where a third party holds a copy of the code that's released to you in set circumstances. It won't suit every purchase, and it's worth getting a solicitor's view on the wording, but it's a question worth asking before you sign.

5. Write a one-page plan B. If this system vanished, how would you take orders, answer customers and tell them what's going on? A phone number, a shared inbox, a simple holding page and a paper form might be enough for a week. The time to work that out is not the morning it happens, with the phone ringing.

Where owning it helps, and where it doesn't

This is where owning your software earns its keep. If you hold the code, no single company going under takes it away from you. With custom software you should own the code outright, and it should be written in something another competent developer could pick up.

That doesn't make it free of risk, and I'd be wary of anyone who says it does. Owned software still needs hosting, backups, updates and someone who understands it. You can own your code and still get stuck if your one developer disappears, which is why we have a page about exactly that: what to do when your developer has left. Owning it gives you options. It doesn't give you a plan. That part's still on you.

So I wouldn't rush to replace anything because of this story. For most of what you use, a good supplier and a tested export is the right answer. Keep the ownership question for the handful of systems your business would actually stop without.

The short version

Every small firm has a list of things it would need if a supplier disappeared overnight. If yours isn't written down, an hour this week fixes that.

If you'd like someone to go through it with you, or you've got bespoke software you'd like someone to look after, drop us a line and we'll tell you honestly whether you need it.

Cheers, Rob

Tell us what you've got

It goes straight to Rob and Jase. You'll hear back from one of us, usually the same day, and we'll tell you honestly whether we're the right people.