Web designers are great. They take your business, your idea, or your project and turn it into a visual experience. They make it look beautiful, readable, and engaging. They know how to hold a customer’s attention with layout, colour, structure, and flow. And those things matter — a lot. But here’s the thing:
Design and aesthetics are only half the equation.
The other half? The technical side. And this is where a surprising number of web designers drop the ball.
As someone who’s spent over 12 years working in IT, specifically with an MSP (Managed Service Provider), I’ve seen more web-related disasters than I care to count — most of them completely avoidable if the person building the website had even a basic understanding of how the internet works.
This post is for the business owner, the startup founder, the person who just wants their website to work and not break everything else around it.
Let me explain why who you pick to build (and host) your website really, truly matters.
My Background (So You Know I’m Not Just Ranting)
I’ve worked in IT for over a decade, helping small businesses to enterprise-level clients manage everything from servers to user accounts, phone systems, VPNs, cloud apps, and of course — websites. I’ve worked side-by-side with clients to untangle issues caused by poorly built websites and bad hosting setups.
I’ve seen businesses lose emails, break their internal systems, and go offline entirely — all because someone’s “web guy” didn’t understand how DNS works.
This isn’t about gatekeeping. This is about risk. And the truth is, many web designers — even the ones who are amazingat design — don’t understand the systems their work plugs into.
And that’s a problem.
A Quick Crash Course: How the Internet Actually Works
Before we get into the horror stories, let’s lay some groundwork.
At the core of how the internet functions is something called DNS — the Domain Name System.
DNS is like the old-school Yellow Pages for the internet. When you type in a website name (like bitstreammedia.com.au), DNS tells your browser where to go — like which server hosts the website, where the email should be delivered, and more.
There are three core components:
The domain name (your
mybusiness.com.au)DNS management (where the DNS records are stored and edited)
The destination services (your website server, your email provider, etc.)
These three things can — and often do — live on different platforms. That’s fine. But it means someone needs to know how they all fit together.
DNS records come in many types, including:
A Record – Points a domain/subdomain to an IP address (for websites)
CNAME Record – An alias for another domain (e.g.
www→yourdomain.com)MX Record – Directs email to your mail provider
TXT Records – Used for SPF, DKIM, DMARC (email validation)
SRV, AAAA, NS, and more – Used for specific services or setups
Most web designers only know about A records and CNAMEs. Few know how to set up email authentication, deal with SPF/DKIM issues, or understand how changing nameservers can impact a whole business.
And that brings us to…
Real Examples from the IT Trenches
1. The Case of the Deleted Website
A client moved their domain and DNS hosting to our MSP for easier management — but we left the website hosting with their existing designer. The A records were set to continue pointing to their web host. The site was live. Everything was working.
Until it wasn’t.
The designer, seeing that the domain no longer “lived” on their system, assumed the service was cancelled. So they shut down the website. Deleted everything. No backup. No warning.
When the client asked what happened, the designer tried to blame us, saying we broke it by moving the DNS. Except we didn’t. The records were still live. You could do a public DIG lookup and see it for yourself.
The result? The client lost their entire site and had to rebuild from scratch. We helped them get some compensation, but the damage was done.
2. The Hardcoded Nightmare
I’ve seen designers hand off completed websites with every internal link hardcoded to their development server URL. Instead of relative links (/contact), they use full URLs like http://dev.webagency.com/clientsite/contact.
Guess what happens when we upload that site to the client’s domain? Everything still points to the developer’s server — or worse, breaks entirely.
We’ve had to comb through every menu, every button, every page, fixing links one-by-one. That’s time the client paid for unnecessarily.
3. The Nameserver Disaster
One of the most common problems: designers ask clients to change their nameservers to the designer’s platform. The designer then sets up DNS records — for the website only.
What they don’t realize (or check) is that the domain also handles:
Business email (Google/Microsoft)
Internal services like VPN access
Intranet portals
Remote office connections
VoIP phone systems
One change. Everything offline. It can take hours to identify and up to 48 hours to fix due to DNS propagation.
We’ve had furious clients call after losing phones, emails, and access to core systems — all because their designer “just needed control of the domain.”
4. The WordPress Plugin Hoarder
We’ve inherited sites with 30+ plugins — half of them unused, many out of date, and a few completely broken. This isn’t just clutter — it’s a security risk and a performance killer.
Designers who are great with visuals often install every plugin they think might help, test nothing, and leave a digital junk drawer behind.
5. The Email Ignorance Epidemic
This one’s big. Email is harder than it used to be. Years ago, you could send email from a contact form and it would “just work.” Today, with spam filters and authentication protocols (SPF, DKIM, DMARC), it’s way more complex.
A contact form that sends from [email protected] without proper setup will likely never reach you. Or worse — it will go to spam and you won’t even know.
I’ve seen designers say “we don’t know why it’s not sending” — and then blame the host. Or worse, blame the client.
Why This All Matters
Your website doesn’t exist in a vacuum. It’s part of a broader network of services and systems — your email, your documents, your phone calls, your CRM.
When you pick someone to design or host your site, you’re trusting them with a lot more than just a homepage.
They may be:
Updating your DNS (which can break your business if done wrong)
Replacing email configurations (affecting deliverability or access)
Uploading insecure files or untested plugins (inviting exploits)
Linking improperly (damaging SEO or usability)
Using unreliable hosting (causing slowdowns or downtime)
What to Look For in a Web Designer (From an IT Guy Who’s Seen It All)
✅ Do they understand DNS and how to protect non-website services?
✅ Can they work with your IT team, not against them?
✅ Do they consider website performance and not just the design?
✅ Are they proactive about email deliverability?
✅ Do they test before handing off?
✅ Will they let you keep control of your domain and DNS — or try to lock it up?
✅ Are they transparent about what they manage and why?
If they shrug when you say SPF or panic when you mention a VPN — it’s probably a red flag.
Our Approach at Bitstream Media
At Bitstream Media, we’ve walked the line between web and IT. We speak both languages fluently.
We design with intention — but we also configure, test, and integrate everything correctly. That means:
We know how DNS works. We won’t take your domain hostage.
We liaise with your IT provider if needed (and they’ll actually enjoy the chat).
We secure and optimize your site — and keep things clean.
We validate your email systems so you actually get form submissions.
We don’t break your business trying to launch your blog.
Final Thoughts
Web designers are artists, storytellers, and builders. But your business needs more than just a pretty site — it needs one that’s technically sound, reliable, and well-integrated with the rest of your infrastructure.
Don’t settle for a site that looks right but causes headaches behind the scenes.
Choose a designer who understands the full picture — or at the very least, one who’s willing to collaborate with the people who do.
Because when websites go wrong, it’s usually not the design that’s to blame — it’s the part nobody sees until it breaks.
And trust me… we’ve seen it break.
