Before you read any further, do this. Open your business website on your phone, fill in the contact form with a test message, and send it. Then go and find out where that message landed: which inbox, which folder, and how long it took.
If it showed up in your main inbox within a minute, good. If it landed in spam, arrived an hour later, or never arrived at all, you have just found something your developer may never have checked. And it is one of seven things like it.
This is not a post about bad developers. Most of the developers we know do what they were hired to do, which is build what is in the brief. The trouble is that the brief almost never mentions the work that keeps the thing alive after it is built.
Unlisted work does not get quoted, does not get done, and does not get noticed until it is missing.
So here is the unwritten part of the job, as we see it. Where we are giving an opinion rather than describing established practice, we will say so.
01 Your contact form may be lying to you
Many websites send form messages through the hosting server’s default mail function. Mail sent that way often fails the checks that receiving mailboxes run, so it either lands in spam or gets dropped without a trace. The usual fix has two parts: send the mail through a properly authenticated email service, and make sure your domain has the DNS records (called SPF, DKIM and DMARC) that let other mail systems verify an email really came from you.
The second half matters just as much. If sending fails, the visitor should be told, and the submission should also be saved somewhere on the site itself, so that a failed email is an inconvenience rather than a lost client. How your particular site is wired depends on how it was built, which is why the test at the top of this post beats any assumption.
02 Nobody should ever edit the live site
A developer who changes files directly on the live server is renovating a shop while customers are shopping in it. Sometimes it goes fine. Sometimes the whole front of the shop falls off on a Monday morning.
Two practices prevent this. The first is version control, usually Git: a complete record of every change, who made it, and how to undo it. The second is a staging copy, a private duplicate of the site where changes are tried before they go live. Without them, “fix the footer” and “accidentally take the site down for an afternoon” are the same action with different luck. Version control is also what allows a different developer to pick up the work later without guessing. If the history of your website lives in zip files named “final”, “final2” and “final-really”, then it has no history.
03 A backup you have never restored is a hope
Most hosting providers offer some kind of backup. What varies, and what rarely gets checked, is whether it is switched on, how often it runs, where the copies are stored, and whether anyone has ever restored one to see if it works. Backups stored on the same server as the website vanish with it, which is exactly the scenario they exist for.
Picture the day a plugin update breaks the site, or the site is compromised. The first question anyone asks is when the last clean copy was made. You want that answer to be a date, not a pause. Ask your developer three things: when was the last backup, where is it kept, and when did someone last restore it into a test environment to confirm it is usable. If the answer to the third is “never”, you do not yet have a backup. You have an intention.
04 Someone should hear about the outage before your customer does
Websites go down. Hosting hiccups, a certificate expires, a domain renewal gets missed, a bad update goes out. A down site is a problem; a site that has been down for two days without anyone knowing is a different and worse problem.
Uptime monitoring checks your site every few minutes and alerts a person when it stops responding. Error monitoring catches the quieter failures, such as a checkout that throws an error for some visitors while the homepage looks perfect. Several services offer free tiers for basic uptime checks, though limits change, so check the current terms rather than relying on us for specifics. The detail people skip is where the alert goes. It has to reach a human who will see it and can act, not an inbox that nobody opens. Which, if you tried the test at the top, may sound familiar.
05 It works on the developer’s laptop. Test it on a customer’s phone.
Developers tend to work on good laptops, large screens and decent connections. Your customers meet your website on whatever phone and data connection they happen to have at that moment. By most published market-share trackers, Android dominates in Nigeria; we are deliberately not quoting a percentage because it moves, so check a current source before you repeat one.
Here is a ten-minute test. Borrow a mid-range Android phone, switch off Wi-Fi, and load your site over mobile data. Watch how long the first screen takes, whether the buttons are easy to tap with a thumb, whether the text is readable without zooming, and whether a heavy banner image is still loading when you would have given up. Browser developer tools can also simulate slow connections, so a developer has no excuse for not trying this. A site that feels fine on the developer’s machine and sluggish on a modest phone probably loses visitors silently, because slow loading rarely shows up as an error anywhere. That is our reading of how these failures behave, not a measured figure.
06 Passwords, keys and the shared login
Three habits cause trouble here. The first is one shared admin login that everyone uses, so nobody can tell who changed what. The second is credentials sitting inside the project files: database passwords, payment keys, email service keys. When those files get zipped and passed around, or pushed to a public repository by mistake, the keys travel with them. The third is access that never gets removed when someone stops working on the project.
The practice we would hold a developer to is simple. Secrets live in the server’s configuration, not in the code. Each person has their own account with only the access they need. Two-factor authentication is switched on for hosting, the domain registrar and the admin area. And when a person leaves the project, their access ends the same day.
07 Can you tell whether the website is working?
A website can be live, fast and beautiful and still leave you unable to answer the only question that matters: is it bringing in business? Many sites go live with nothing set up to say so.
The fix is not a bigger dashboard. It is a handful of tracked actions that map to real value for your business: a form submission, a tap on the WhatsApp button, a tap on the phone number, a quote request. Analytics tools can record each of these as an event. Without them, the report you receive says traffic went up, and you have no idea whether any of those visitors became enquiries.
How to raise this without starting a fight
Send these to your developer as questions, not accusations. A good developer will answer one of two ways: “yes, that is handled, here it is,” or “no, here is what it would take.” Both are healthy answers.
Be fair about cost, too. Some of this is real work that takes real hours, and a fair developer will tell you what is included in your price and what is not. Some of it, like staging, backups and basic monitoring, arguably belongs in the original scope, but that is our opinion and not a universal rule. What should worry you is defensiveness, or being told “don’t worry about that” without being shown anything.
Go and send that test message. Then ask the other six.
