Insights on strategy, websites, UX, and digital growth

We've had a slightly uncomfortable run of conversations recently.

Several businesses have approached us because something has gone wrong with their website and the person they normally rely on either can't fix it, won't fix it, or has simply disappeared.

The examples that prompted this article all happen to involve WordPress websites, although WordPress itself isn't really the point.

In one case particularly, the website wasn't just part of the business. It was one of the principal ways the business traded, sold and communicated with its customers. When it stopped working properly, it became a significant commercial problem very quickly.

Fortunately, our experienced WordPress developers have been able to unpick the problems we've inherited.

But it has made me think about how difficult it can be for a business to judge what it is actually buying when it appoints someone to build or look after a website.

Making websites has become easier

There has never been a shortage of people who can build a website, but the barriers to doing so have fallen considerably.

WordPress has thousands of plugins that can add surprisingly sophisticated functionality without writing much, if any, bespoke code. Platforms such as Wix, Squarespace, Webflow and Shopify make it possible to assemble increasingly capable websites from existing components.

Now AI is taking that another fairly substantial step forward.

None of this is inherently bad.

These tools have made good technology available to businesses that might once have been unable to afford it. We use plenty of third-party software ourselves because rebuilding something that already exists and works perfectly well would often be a waste of the client's money.

The problem comes when ease of building is confused with understanding what's been built.

You can install a plugin that solves a problem today. But what happens when that plugin needs updating? What if its developer stops supporting it? What if another part of the website changes and the two no longer work together?

Most of the time, nothing dramatic happens.

Until it does.

The things that probably won't happen

One of the less glamorous parts of developing software is spending quite a lot of time talking about things that probably won't happen.

• What happens if this system doesn't respond?
• What happens if a payment is taken but the order isn't created?
• What happens if two people try to buy the last available item?
• What happens if somebody enters something we aren't expecting?

Quite often the perfectly reasonable response is: "But that's very unlikely" or "That does happen, but very rarely".

It may well be.

But the question is what happens if or when it does?

If the answer is that somebody receives an error message and tries again, perhaps that's a perfectly acceptable risk. But if the answer is that £20,000 worth of orders occasionally disappear into a hole, you might want to give it a little more thought.

A lot of experience in web development is really accumulated knowledge of things that can go wrong. Yes, we really are a curmudegeonly bunch at heart.

That doesn't mean trying to engineer every conceivable risk out of a project. You'd rapidly make most projects unaffordable.

It means recognising the risks, understanding the consequences and making conscious decisions about them.

The power drill analogy

You can buy an excellent drill without knowing very much about, DIY or buildings. I certainly have done the former and I am definitely the latter.

Making a hole in a wall is the easy part. (Unless its a cob wall in a 500 year old cottage, but that's another story for another time.)

Knowing whether there is a water pipe or electrical cable behind it is where experience starts to matter. And probably more besides, depending on what the hole is going to be for...

The same applies to website technology.

The tools are becoming easier to use. AI will make them easier still. But knowing where the risks are, which shortcuts are sensible and which ones may come back to haunt you is something rather different.

So how do you choose a web developer?

After one particularly bad run of experiences with previous developers, one of the businesses that recently approached us sent through a 45-question supplier due diligence questionnaire.

It was good. Thorough, sensible and, for the size of the organisation, possibly a little terrifying.

Most businesses aren't going to put a prospective web developer through a 45-point assessment, nor do I think they necessarily should.

But some of the questions behind it were very good.

So I've distilled them, along with a few questions we think are worth adding, into ten things I would ask anyone who was going to build or take responsibility for an important website.

1. Tell me about something that has gone wrong

We normally ask prospective suppliers for case studies of what they've built successfully. The wins. What's gone well.

Perhaps we should ask them what has broken too.

Technology goes wrong. People make mistakes. Third-party services fail. Updates cause unexpected problems.

I'd be more interested in hearing how somebody dealt with one of those situations than being told nothing ever goes wrong.

What happened? How did they find out? How did they resolve it? What did they change afterwards?

You can learn quite a lot from the answer.

2. What happens if the person who built our website isn't available?

This matters whether you're working with a freelancer, a small studio or a much larger agency.

If the person who understands your website leaves, gets ill, goes on holiday or simply isn't available, can somebody else pick it up?

The answer might involve documentation. It might involve several developers knowing the project. It might simply be a very disciplined way of recording decisions and access.

A small supplier isn't automatically risky and a large supplier isn't automatically safe.

The useful question is how dependent you are on one person.

3. What do we actually own?

This is worth establishing before anything gets built.

• Who owns the domain?
• Who controls the hosting?
• Who owns the code?

Whose accounts are being used for analytics, advertising, plugins and third-party services?

If you decided to move to another provider tomorrow, what could you take with you?

There may be perfectly legitimate reasons why particular technology is licensed rather than owned. You just want to know about them before they matter.

4. What do you think could go wrong?

This might be my favourite question.

Not because you're looking for reasons not to proceed, but because the answer tells you something about how the developer thinks.

• If the website takes payments, what are the awkward scenarios?
• If it connects to another system, what happens when that system is unavailable?
• If customers are entering data, what happens when they do something unexpected?

Someone who has done this for a while will usually start identifying possibilities fairly quickly.

That doesn't mean they all need expensive solutions. Sometimes simply knowing how you would respond is enough.

5. How do you test changes before they go live?

Nobody needs to become an expert in software testing to ask this.

You just want to know whether changes are checked somewhere other than the live website and whether somebody considers what else might have been affected.

For a relatively simple website, that process may itself be relatively simple.

For an ecommerce website taking thousands of orders, you would expect considerably more.

The process should fit the risk.

6. Who keeps everything up to date?

This is particularly relevant to WordPress, where a website can contain software from several different developers.

WordPress itself changes. Plugins change. Hosting software changes. Browsers change. Security vulnerabilities are discovered.

Someone needs to understand who is responsible for keeping on top of it.

And, importantly, what happens when one of those moving parts is no longer maintained.

A website can continue working for a surprisingly long time with an ageing component buried inside it.

Right up until the point that it doesn't.

7. What are you backing up?

Most providers will answer yes if you ask whether the website is backed up.

I'd go one step further and ask:

"Could you restore it?"

A backup that has never been tested is really a hopeful collection of files.

For an important website, you should have some understanding of what's actually being backed up, how frequently and what would actually happen if the website had to be recovered.

8. How will you know if something stops working?

If your website is important to the business, ideally the first person to notice a problem shouldn't be a customer.

There are plenty of ways to monitor websites and the services behind them.

That doesn't mean every business needs 24-hour engineers staring at screens waiting for something to happen.

Again, it's about matching the response to the risk.

If your website is a brochure and generates a handful of enquiries each month, an hour of downtime probably isn't catastrophic.

If it processes most of your company's revenue, you might think differently.

9. What happens if we want to leave?

This is a slightly odd question to ask at the beginning of a relationship, which is probably why it is a useful one.

• How would another developer take over?
• What information would they receive?
• Would they have access to the code, hosting and relevant accounts?
• Would there be any particular costs or technical obstacles involved?

You're not planning for the relationship to fail.

You're making sure your business isn't dependent on it continuing forever.

10. What are we relying on that you don't control?

Almost every website depends on something outside the developer's control.

Payment providers. Hosting platforms. Plugins. APIs. Email services. Search technology. CRM systems. Ecommerce platforms.

There's nothing wrong with that.

But it is useful to understand which bits of your business are dependent on somebody else's technology and what the implications might be if that technology changes.

This is particularly relevant when an apparently simple plugin or service becomes fundamental to the way the business operates.

You don't need all the right answers

I don't think the purpose of these questions is to find a supplier who produces a perfect response to every one.

That supplier probably doesn't exist.

The purpose is to understand the risks you are taking.

There may be a completely rational reason to appoint a single freelance developer rather than a 40-person agency. The freelancer may be excellent, significantly cheaper and entirely appropriate for what you need.

But you should understand what happens if they aren't available.

You might deliberately choose a website that relies heavily on third-party plugins because building all of that functionality from scratch would make no commercial sense.

But you should understand what you are relying on.

Good decisions aren't necessarily the ones with the least risk, they're the ones where the risk has been considered.

What changes with AI?

Probably less than you might think.

AI can now produce working code extraordinarily quickly. It can help diagnose problems, build interfaces, connect systems and dramatically reduce the time involved in some development tasks.

That is already making substantial changes to our industry.

But it also makes the distinction between making something work and understanding whether it should work that way, and HOW it works, increasingly important.

AI hasn't invented this problem.

WordPress plugins, website builders and low-code tools have been moving us in this direction for years.

AI is simply accelerating it.

The questions remain much the same.

• What are we building?
• What are we relying on?
• What happens when something unexpected occurs?
• And who is going to be there to sort it out?

Your website may matter more than you think

For plenty of businesses, a website going offline for a few hours would be annoying but manageable.

For others, it would immediately stop revenue, customer service or important internal processes.

The odd thing is that businesses don't always change the way they manage their website as its importance grows.

Something that began life as a fairly simple marketing site gradually acquires ecommerce, integrations, customer accounts, business logic and years of accumulated functionality.

Eventually it becomes important infrastructure.

But it may still be supported as though it were the little website somebody built ten years ago.

If your business depends on your website, it is worth knowing who you are depending on too.

A practical checklist

Before appointing someone to build, maintain or support an important website, make sure you can answer these questions:

1. Who owns the domain, hosting, code and key accounts?
2. Could someone else take over if the main developer became unavailable?
3. Do they have a clear process for testing changes before they go live?
4. Who is responsible for updates, maintenance and security?
5. Is the website backed up, and can those backups actually be restored?
6. How will problems be detected, and who responds when something fails?
7. What third-party services, plugins or integrations does the website depend on?
8. Have the main failure scenarios and edge cases been considered?
9. If you wanted to change provider, could you do so without unnecessary technical or contractual obstacles?
10. Can the provider give you specific examples of how they've dealt with problems when things went wrong?

You don't need perfect answers to every question.

You do need to know what you're relying on.