Blog

Building Reliability Part 1: How To Build a Reliable Website

The Natives

We native inhabitants of web development shops tend to obsess about the newest addition to the tech stack. Or we think too much about the next big technical challenge. Sometimes we spend all of our time playing foosball because we're posing as tech people. We flit around developing the newest coolest Javascript framework and we give very little thought to whether such a thing is even needed. We're totally ignoring our client's actual needs. Our clients need reliability.

Reliability

If you Google 'reliable website' you get a bunch of hits about how to tell if a website's information is truthful or dependable. You get results on how to detect scams. When I say 'reliable website' I’m referring to whether the website generates revenue reliably. And when I say that, what I really mean is something even more fundamental: Does the website quickly and easily meet the needs of its user?

Flow

There's an even better way to define website reliability, still with a question: Does the website flow?

A good website is characterized by smooth, dependable, unimpeded flow. The customers have a need, an ailment, a desire of some kind. The website and the marketing that supports it finds the customer out on a crowded internet. It guides the customer into the website, encouraging their motivation along the way. Then, once in the website, the customer is guided through the process of understanding and having their needs met. Lastly, the customer is sent deftly out into a suitable fulfillment system. At this point, the team of humans dedicated to taking care of the customer must have the website-integrated tools available to do so.

Website reliability is about reliable flow. Reliable flow is about the In, Through, and Out of customer desire.

Our Poor Clients

So here we are, playing foosball or ping pong, sipping on Matcha Lattes, arguing about the newest CSS build automation techniques, totally ignoring what our clients are really asking us to do. We think they want us to add even more layers of complexity to their website's tech stack. We think they want us to be clever and know the newest, coolest, I-know-something-you-don't-know web developer trifle.

It's high time we dropped our own narcissism, took off our giant headphones, and tried listening to our clients for a change.

To Create Reliability We Must Be Reliable

A reliable website is a fast website.
Our client's customers have more than one problem. The faster the website can solve their problem the less it will resist them. This means the pages must load as quickly as possible. And there's an entire science behind this.

A reliable website is a well-designed website.
Our client's customers are busy. They should not be required to think about stuff that we should have thought of for them. This means the content architecture must be intuitive. This means the graphic design should reassure and motivate the customer, but still stay out of the way. This means the technical execution of the website should be bug-free. There's an entire science behind website usability.

A reliable website is a secure website.
Our clients are going to ask their customers to provide sensitive personal data. In most cases having this data will help to serve the customer better. But the risk is that the website can be hacked and this data exposed. Relatedly, an insecure website can be hacked to show misleading information to a customer or redirect the customer to a different website altogether. There's an entire science behind website security.

Many more 'web sciences' are involved in making a website reliable. How can we web developers hope to master all that's necessary to deliver reliability to our clients? Can't we just specialize in something? Your client does not have the luxury of specializing.

The fact is for any given website, there is exactly one person who has to own the big picture. This is your client. Are you going to have this person's back or not?

I wrote a book about how to start fixing the Web Reliability problem. You can check it out here.