When a healthcare client’s website was unexpectedly taken offline by their previous developer, Solspace stepped in to restore it. In this solo episode, Mitchell Kimbrough shares the behind-the-scenes story of how they resolved the crisis and why businesses must prioritize web reliability. If you’ve ever been left in a lurch by a web developer, wondered how to navigate a website emergency, or how to choose a trustworthy web developer, this episode is for you.
[Music] Welcome to the Solspace Podcast. Thanks for listening.
Mitchell: Hi everybody. Welcome back to the Solspace podcast. This is Mitchell Kimbrough, founder of Solspace. I'm your host.
We thought we would do a solo cast this time around because I just finished a project restoring and recovering a website that had gone offline for a new client.
It turns out that the way the story played out, it's a really good illustration of a lot of the principles that I had in mind when I wrote the book Web Reliability. You can find it on our website.
So the story goes like this. I get an email from a client on a Friday afternoon and all of a sudden they see that their website is offline. It's just not responding. There's nothing on the web when you hit their URL.
This is a healthcare organization, so this is a regional physician's office with about three offices, sort of on the West Coast. It's not a giant company. There's about 20 physicians who work at the various offices and the patients pay their bills by going to the website and finding their way to the payment system, which is a separate link, but it's all routed through the main website. So all these people are accustomed on a daily basis to going to the domain name for this client, finding the website, getting set up to pay their bill.
The website was offline. So why was the website offline? The website was turned off by the previous developer who built the website. And it turns out it was a new website.
They contacted Solspace because the website was built on CraftCMS. The client knew at least that much. The developer had turned the website off because I would say they'd had a falling out. They had a dispute. The developer, once I contacted that person, suggested that no, it was mutual, but I think my client made things clear. It was not mutual. There was a serious rift.
So what happened? Well, from as much as I can patch together based on looking at the code and talking to the client and talking to the other marketing members of the team, it looks like the developer talked my client into allowing him to build them a website without telling them about the underlying technology. So, he decided to build a website on craft.
They didn't know what craft was. They didn't get a choice. They didn't get a demo. They didn't get to experience it. He built a headless craft website, which is not in and of itself a problem as long as your client knows what they're getting into and what they're signing up for.
It sounds like this client was sold a bill of goods and they weren't really brought along to understand and be part of the decision-making process in the technology. So, I think that the developer had a difficult time getting the website finished. It was complicated in a lot of technical ways. One, it was a headless website, and it didn't need to be.
So, what is a headless website? Headless website is one that has a backend that served from a server somewhere by way of an API, a front end that makes calls to that backend to get the content that the pages need. And those two things are separated. So instead of the content management system generating the pages and sending those to the user's browser, the pages are generated with something like Vue.js or React. And then that code goes to the server and grabs the content, shows it to the user. It's subtle and it's, you know, it's an interesting technology. It has its place.
These poor clients didn't need it. They didn't need that level of complexity. They didn't need that set of problems. From what I could tell, the developer got in over his head. He couldn't finish the project. His technology choices were too complicated. He probably was going over budget. He was starting to lose money, and he wanted to get out of the deal. So, he gave my client something like 60 days’ notice, maybe 90 days’ notice or whatever to go find another developer to take over the website.
It had been launched. It was live. And the developer said, you're going to need to find someone who's pretty technically skilled because what we built is a pretty complicated website. Not everybody can take care of it. My client had a really difficult time finding someone because they didn't know what they had. They didn't really know what questions to ask. They didn't know how to proceed.
So, weeks and months went by, and the developer said, you're at the end of your period. I'm turning your website off. We have concluded business. We are done. And he left him in the lurch.
So, they reached out and found Solspace. They had talked to a few other agencies, but they found us, reached me on a Friday and I started gathering information and started telling them what I needed in order to get the website up and running. And it took a few back and forth emails with the previous developer until we had everything we need to restore the website.
Because it was headless, it was pretty complicated to get it up and running. There was no information from the developer, no readme, no details, nothing. But I managed to get it up and running because I had some experience with the technology. Certainly knew craft well enough to know the ins and outs there. A new Vue.js which was the front end system of this headless website.
So anyway, got it up and running after some time, set it up on new hosting, made arrangements with the IT team the client has to make the DNS changes and all that stuff.
So why am I telling this story on a podcast? What's this about? Well, this is about web reliability. You know, you have a problem when the website's offline. You know you have a problem when the website crashes, when it's just plain dead and not even responsive, not even there.
That's a web reliability problem. A website should be reliable. It should be a reliable source of revenue for the company who owns it. It's a business asset. And when it's totally dead, it's not useful. It's probably the worst case I've ever seen.
Now why a developer would choose to turn off a client's website, even though they had paid, they were current on their bill. There's no reason to cut them off and have an impact, negative impact on their business. So how could the client have avoided this? Really the onus is on the client to make a good choice and to fire the developer if they prove to not be doing their job.
So how do you know? What do you got to look for? There's a few things you can keep in mind. If you're a client out there and you've experienced this kind of thing before, or you're concerned that you might, you're about to choose a vendor to build a website for you and you want to make a good choice, here's some things to think about.
First of all, the question of how do you know when you're working with someone reliable? How can you tell? Apparently when my client was first engaging with this developer and they'd been on retainer with this developer for a few years, a low-level retainer that really wasn't producing value, there wasn't really anything happening with it.
They had the impression that the developer was truthful and giving them what they needed and acting in good faith, but they didn't have proof. So, when you're asking yourself, when you're about to choose an agency or a freelancer or a vendor to do some web development work for you, of course you need to have someone who's reliable. You need to have someone trustworthy.
How do you know? Well, you trust but verify. You test them. You look for objective data to confirm that you're dealing with someone who knows what they're talking about, who's telling you the truth, who's going to guide you in the right direction.
So how do you get that proof? Ask for a proof of concept. Ask your developer, what are you going to, are you going to just, is this WordPress? You're building us a WordPress website. It's not? What is it? It's craft? A craft CMS? What is a craft website? What is that? Make them explain it.
Oh, don't worry about it. It'll be fine. It's great. It's a great system. You'll love it. What if I don't love it? Can I see it in action now? Is there a demo? Can I take a look at something before you put us on that? I think I get the choice, don't I? Assert yourself.
One of the challenges in the web development space is that most websites these days, if they're not one of those self-serve Wix or Squarespace or Shopify websites, are pretty complicated. You need some web developer help to help with the kinds of API integrations you're running these days, the more complex sort of data structures, landing page capabilities, and so forth.
So, you need some help. You need to ask for and assert yourself. You need to ask for proof. You need to validate. And you need to try to put yourself in a position where you can push back on the person who's making some sort of claim about how great the website's going to be.
So a second thing to consider, how do you know that the suggestion that your developer is making to you about a technology choice, how do you know that that's a reliable suggestion? How do you know that the technology they're recommending to you is going to work for you? How do you know that it's not going to be more expensive than necessary? Is it overcomplicated? How do you know? We ask for proof.
First of all, you can ask around. You can talk to other friends and colleagues. You can go on LinkedIn and just kind of poke around, do some searches for the technology they're talking about. If they can't give you straight answers about how they intend to build this thing, this website, or this website feature, then you're not ready to move forward.
So ask for proof. Ask for a proof of concept. Ask to see something else on the web using the same technology they're recommending. You're about to spend a lot of money on this, and so you should inform yourself about what you're about to buy. It would be nice and convenient if you could just trust, but trust but verify is actually the rule.
So the third piece is, how do you know when the developer you're working with is getting in over their head? How do you know when they think they're telling the truth when they say, yeah, everything's fine. We're going to be able to hit a couple of snags, a couple of difficult things, but we're going to sort it out. We'll be delayed about a week. No big deal. Are you on budget? Yeah, I think so. I think we're okay. How do you know when the developer's in over their heads and they're not telling themselves the truth, and by extension, they're not telling you the truth? How can you tell? Again, ask for proof.
This is the winning formula right here. According to some of the things that I laid out in the Web Reliability book, you want to structure projects and you want to build up teams in such a way that there are clear breakpoints. They're just milestones all along the path toward a launch.
You want to see proof of life, proof of concept on a regular basis, especially when you're adopting some new technology or trying to do something that you haven't done with the web before or that the website hasn't done before, that your developer hasn't done before.
In all those cases, you want to set up the project so that you can have really clear and objective failure points so that you could objectively push back and say, okay, I thought we were going to be at this stage by this date for this budget. What happened? Everything's okay. I think we'll figure it out. No, stop, because we agreed that we would stop at this point if we hadn't reached the milestone. If you were not able to get the website to connect to Salesforce and exchange data back and forth bi-directionally by now, by January 3rd, then we were going to stop and reassess. So now we need to stop and reassess. It's in the contract or it's in the project plan or it's something we agreed on an email or whatever. So you set up the project so that they're structured so that you see proof along the way. You see validation as you go, and you get to check the work.
If you set up the relationship in advance where the developer, the agency, that freelancer you're dealing with knows that they're going to be, their work is going to be checked. They're going to be asked for evidence and proof. If you start that cadence and pattern early on, nobody has to get their feelings hurt. Nobody has to be annoyed. And who cares? It's your money and your time and your business. It's your website. You should push back and ask for proof. You should demand that stuff.
When we find at Solspace that we're dealing with a client who just wants to trust, throw their hands up and say, you guys take care of it, just make it happen. We know we're in trouble because we know we're not having a client who's going to be engaged in the process. We may make some suggestions that sound great to us, but to them, maybe it's a problem, but they don't speak up because they'd rather be quiet and trust.
The client, you need to engage. You need to engage with the project and engage with the process so that you can get a good outcome. And here's the key that happened with this client that I've been talking about.
Once we started talking and I started asking them questions about certain aspects of the technology, and they didn't know what those things were. You know, I said, is this website behind Cloudflare? What's a Cloudflare? Oh, do you know what caching is? No. What's caching? Do you know what a CDN is? No. Do you know what a DDoS attack is? No. I take my time and I explain it. If you're not dealing with a developer who's going to take their time to explain some of these things to you, then you're not dealing with someone who's going to get you a good result.
You're not dealing with someone who, in the end, you're going to be satisfied with the relationship and the work product. So in this case, it became clear that I wanted to catch myself every time I said something technical. Every time I threw some jargon out there, I wanted to stop and check in and see if I had an opportunity to teach my client something they didn't know.
I find that fun. It's engaging to teach someone something new, especially when it's something that comes easy to me and my team, but it's something completely unheard of to them. I like to sort of get them up to speed with some of the decisions they're going to have to make and some of the technology choices they're going to have to live with for a few years. I like an informed client. So, we took our time. Did it take a lot of time? Actually, no.
It takes two, three, four minutes to explain to a client what a CDN is or to explain what a headless website is or to explain why CORS matters or why accessibility is an issue on their website. These things don't take a long time to explain, especially if you know what you're talking about. So, this has been a podcast about what I call web reliability.
Web reliability really, for the most part, comes down to human beings, team, people working well together. I tried to give you some suggestions about how you could evaluate objectively the person that you're dealing with. You want to trust people because it's less confrontational.
You don't want to push back. You don't want to ask for objective data and facts and evidence because it feels too confrontational. It feels like you're not fostering a good relationship.
But what you're doing is you're not creating a foundation for a real relationship. If you're not creating a real dialogue based on facts and evidence and data, then you're really not going to get anywhere. You're going to probably get into some trouble.
I'm afraid that's what happened with this client. The good news, they're really nice people, really easy to work with, very, very smart, easy to bring up to speed on all the technology choices they ended up getting saddled with. And now their website is back up and running. Looks good. It's fast. It's secure.
There's a few things I'd like to do to it, but we'll hopefully get to that in due course. At any rate, thanks for tuning in to my first solo cast.
Thanks, everybody.
[Music] You've been listening to the Solspace Podcast.