BEFORE YOU HIRE A WEB DESIGNER, READ THIS

Why Most Websites Fail Their Owners

When a new client comes to me, I almost always start by auditing what they already have. And almost every time, the same issues appear — not because the previous designer was malicious, but because no one told them these things mattered, and no one thought to ask.

Here's what I find, over and over again:

Custom code no one can maintain — and no one tells you until it's too late.

This is the issue I see cause the most long-term damage. Custom-coded websites look impressive. They can do things templates or builders can't. And for certain projects — complex web applications, highly specific functionality, enterprise-level needs — custom development is the right call. But for the vast majority of small & local businesses, nonprofits, and independent practices? Custom code is a liability dressed up as a premium service that will cause you issues long term. I'll stand by that promise.

Here's what happens. A developer builds you something beautiful, entirely from scratch or heavily modified with custom code layered on top of a CMS. It works perfectly at launch. Then six months later, a plugin updates and breaks something. Or if you're on a builder like Squarespace, they change how they handle a certain attribute and suddenly your navigation looks wrong. Or you want to refresh the homepage layout. Or you just need to update your services page or add a photo where one isn't right now.

Who fixes it? The original developer, if they're still around and still taking clients. If not — and often they're not — you're starting from scratch with someone new who has to reverse-engineer someone else's code before they can touch anything. Meanwhile your team can't make a single change without risking breaking something else.

I've seen this play out with clients who spent significant money on a custom-coded site (upwards of $30, $50, $70K(!!)) and then spent more money over the following years maintaining it, patching it, and eventually rebuilding it entirely because it had become impossible to update.

The honest truth is that for most teams, a well-built site on a platform like WordPress with Kadence, Squarespace, or Webflow gives you 95% of what custom code can do — with the critical difference that your team can actually use it. You can update copy, swap out images, add a new service page, change a layout, without filing a support ticket or waiting on a developer. When the platform updates, the builder updates with it. When you want a new look in two years, you're updating a design system, not rebuilding a codebase.

Custom code has its place. Small targeted tweaks, specific integrations (like a custom-coded fundraising tracker I built for the Center for Women's Leadership), functionality a platform genuinely can't handle — those are legitimate use cases. But "we built it custom" is not inherently a sign of quality. Sometimes it's a sign that no one thought about what happens after launch.

And to be clear: a site built on Squarespace isn't a template site. It's a custom website built on a sustainable platform. The difference is that the infrastructure is maintained by a team of engineers so you don't have to. Everything above the platform level — the design, the layout, the content structure, the brand system, the integrations — is still completely custom to you. I've never built two sites that look alike. The platform is the foundation, not the ceiling.

No legal pages.

No privacy policy. No terms of service. No accessibility statement. This is my soapbox and I'll stand on it: legal pages are not optional. A privacy policy is legally required in most jurisdictions the moment your site collects any user data — and it almost certainly does, even if just through a contact form or Google Analytics. The GDPR in Europe, the CCPA in California, and a growing number of state-level laws mean that "I didn't know I needed one" is not a defense. Terms of service protect you when things go sideways with a client or customer. An accessibility statement signals your commitment to inclusion and can matter in legal contexts too.

These pages take time to do right, which is probably why so many designers skip them or treat them as the client's problem. I cover all of this in more depth in my guide on whether your website needs a privacy policy — but the short answer is: yes, it does, and it should have been there from day one.

No SEO foundation.

A site that Google cannot read is a site that might as well not exist, no matter how beautiful it is. And I don't mean complex technical SEO, I mean the basics that should be non-negotiable on every single site that launches.

Title tags that actually describe each page. Meta descriptions written for humans, not just bots. A logical header structure — one H1 per page, H2s and H3s used correctly — so Google understands what the page is about and how the content is organized. Image alt text. A clean XML sitemap submitted to Google Search Console. Canonical tags to prevent duplicate content issues. A robots.txt file that isn't accidentally blocking pages from being indexed.

None of this is advanced. All of it gets skipped constantly. And the cost is that a site launches, sits there looking great, and generates zero organic traffic because Google has no idea how to categorize it.

SEO isn't something you bolt on after the fact. The structure of the site — the URL format, the heading hierarchy, the internal linking — has to be right from the start or you're doing rework later. I wrote a full SEO 101 guide and a guide to local SEO, that walks through the fundamentals if you want to go deeper, but the baseline question to ask any designer is simple: what does your SEO setup look like at launch?

Accessibility ignored entirely.

Accessibility isn't a feature you add when the budget allows. It's a baseline standard that every website should meet and most don't.

What does that actually mean in practice?

• Color contrast ratios that meet WCAG AA standards so text is readable for people with low vision. Images with descriptive alt text so screen readers can interpret them.
• Buttons and links that work with keyboard navigation, not just a mouse.
• Forms that are properly labeled.
• Layouts that don't fall apart on mobile.
• Font sizes that don't require squinting.
• Focus states that are visible so keyboard users know where they are on the page.

Beyond the ethical argument there's a growing legal one. Accessibility lawsuits against websites have been increasing steadily, and while they've historically targeted larger organizations, that's changing. An inaccessible site is also a worse experience for everyone, not just users with disabilities. Slow readers, people on poor connections, someone holding their phone in one hand on a moving bus — good accessibility practice helps all of them too.

I've written about this more in Making Your Brand Accessible and Good Brand and Web Design Is Inclusive if you want to understand what this actually looks like in practice. The short version: ask your designer specifically how they handle accessibility, and if the answer is vague, push harder.

Email records never set up.

SPF, DKIM, and DMARC are DNS records that live in your domain settings and tell email providers — Gmail, Outlook, everyone — that emails coming from your domain are legitimate and authorized. Without them, your emails get flagged as spam. Sometimes they land in junk folders. Sometimes they don't arrive at all.

This matters more than people realize. Your inquiry form confirmation emails. Your client onboarding messages. Your newsletter. Your invoices. All of it is affected. I've seen businesses lose leads because a potential client filled out a contact form, never got a confirmation, assumed something was broken, and moved on. I've seen newsletters with solid subscriber lists get open rates in the low single digits because half the emails were going to spam. The fix takes about twenty minutes.

Digital infrastructure that doesn't connect.

Your website is not a brochure. It's the hub of your digital operation, or it should be. When it's not connected to the rest of your tools, you end up doing everything twice.

A concrete example: a nonprofit with a donation button on their website that redirects to a third-party platform with no tracking, no CRM integration, and no way to connect donor data back to their email list. Every donation is an isolated transaction. No follow-up automation. No donor journey. No way to measure what's working. The website and the fundraising operation are running in parallel, creating work and losing data at every step.

The same pattern shows up in small businesses with booking systems that don't talk to their CRM, e-commerce stores with no connection to their email platform, service providers with contact forms that dump into a generic inbox with no tagging or routing. These are missed opportunities at every touchpoint.

When I take on a project, one of the first things I do is map out the full digital ecosystem. What tools exist, how they currently connect, and what the gaps are. The website gets built to sit at the center of that system, not alongside it.