Every day is a learning day, and everyone makes mistakes. Including us.
This is one of ours, told straight, because hiding it would make us exactly the kind of developer this post warns you about.
At 9:10 on a Thursday morning, one wrong command deleted our entire server.
Not a client's server. Ours. The one that held our own website, our client portal, our customer records, and the staging sites we were building for customers at the time. One command, and in the time it takes to press enter, all of it was gone.
If you run a business, you know the feeling of a stomach dropping. Imagine it at the exact moment you realise you have just erased your own company's data, and the only person responsible is you.
That was us. In July. And the reason I am telling you about it is not to confess. It is because the thing that saved us is the exact thing most web developers do not do.
What actually happened
I will spare you the technical detail, because it does not matter. Here is the version that matters.
We were updating our website and ran a command that was supposed to copy the new files over the old ones. That command had a switch on it, one extra word, that told it to delete anything that was not in the new copy.
The problem is that our website was not the only thing living on that server. It shared space with our client portal, our customer database, and the test versions of sites we were building. The command did not know the difference. It just deleted everything that did not match.
Twenty-nine directories. The customer portal. The database that holds every enquiry, every invoice, every change request from every client. Gone.
What saved us
Not luck. Backups.
Here is the thing I want every business owner to hear: the reason we were back online in fifteen minutes is not that we are clever. It is that we had planned for the day something went wrong.
Every website we build has its code stored somewhere safe, separate from the live site. Every site has a recovery plan. Every client's work exists in more than one place, so that if one copy disappears, the other one is still there.
When the server went down, we did not have to rebuild anything from scratch. We had the files. We had the plan. We pushed them back up, checked each one was working, and fifteen minutes later it was all back.
The only thing we lost permanently was a folder of test sites. Staging versions. Half-built, and rebuildable. Annoying, but not a disaster.
A disaster is what happens when that command gets run by a developer who does not keep backups. A disaster is a business that wakes up to find its website, its customer data, and its booking system gone, and nobody knows how to get any of it back.
The corner most developers cut
When you hire a cheap web developer, you are not just paying for a cheaper website. You are paying for cheaper habits.
The corner that gets cut first is almost always backups. Backups are invisible. They do not make the website look better. They do not show up in a demo. A client never asks to see the backup system, so a lazy developer never builds one.
Until the day it matters. And on that day, the difference between a fifteen minute blip and a business that is offline for a week is one question:
"Does my developer have a recent backup of my site, and do they know how to restore it?"
Most business owners cannot answer that question, because they never thought to ask. And most cheap developers are counting on exactly that.
How to check your own site right now
You do not need to understand the technical side to protect yourself. You need to ask three questions of whoever built, or now looks after, your website.
One: where is my website backed up, and how recent is the last backup? If the answer is vague, or "somewhere", or a shrug, that is your warning sign.
Two: if the site vanished today, how long would it take to get it back? A proper answer is hours, not weeks. If they cannot tell you, they have never tested it.
Three: who else has a copy of my login details? If your developer is the only person holding the keys and they disappear, so does your site. You should have your own access, always.
These are not technical questions. They are ownership questions. And they are the difference between renting your online presence from someone who might vanish, and owning a business asset you can recover.
Why I am telling you this
Because it is embarrassing, and it is true, and if we had not planned for it, we would be telling you a very different story.
We cut no corners on the one thing that mattered, and that is the only reason you are reading this on a working website instead of a holding page. Every site we build gets the same treatment: code stored safely, a recovery plan, and more than one copy of everything.
The cheap option costs more. Sometimes you find that out over two years of hidden maintenance fees. Sometimes you find it out on a Thursday morning when your whole business disappears in a second.
Plan for the day something goes wrong. It will. The only question is whether you are back in fifteen minutes or fighting for your business a week later.
