Do You Need ‘A Website’ or a Product? Balancing Developer Craft with Client Outcomes

“We just need a website.”

I hear this all the time. And honestly, my brain immediately goes into overdrive: user journeys, content strategy, design systems, performance optimization. The full treatment. But here’s the thing—sometimes a client really does just need a website. Not a product. Not a platform. Just a solid, working website.

The trick is knowing when to build something simple that works, and when to invest in something more robust. Get it wrong either way and you’re in trouble.

What Clients Usually Mean by “a Website”

When most clients say they need a website, they’re thinking:

• We need to explain what we do clearly
• We need to look professional and credible
• We need people to be able to contact us, book something, or buy something
• We need to update it ourselves without calling a developer every time

That’s it. They want something that makes their business look good and helps people take action. Nothing wrong with that.

What Developers Usually Mean by “a Good Product”

Meanwhile, developers hear “website” and immediately start thinking:

• How do we structure this so users can actually find things?
• What tech stack makes sense for the long term?
• How fast can we make it load? What about accessibility?
• What happens when they need to add 50 more pages next year?
• How do we keep the design consistent as it grows?

We’re thinking about what happens after launch. About sustainability. About not having to rebuild the whole thing in 18 months because it became a mess.

Where It Gets Messy

This is where projects go sideways. The client wants it done quickly and within budget. The developer wants to build something that won’t fall apart. Both are reasonable positions, but they pull in different directions.

You end up with:

• Timelines that slip because we’re building things the client never asked for
• Budgets that blow out because we underestimated complexity
• Arguments about whether to build custom or use something off-the-shelf
• Debates about whether the design needs to be unique or just needs to work

If you don’t manage this tension, you get scope creep, missed deadlines, and a website that’s expensive but doesn’t actually help the business.

How I Actually Handle This Now

After years of getting this wrong in both directions, here’s what I’ve landed on:

Start with what success looks like

Before talking about tech or design, figure out what the business actually needs. Usually it’s something like “get 20 qualified enquiries a month” or “get people to book consultations.” Write down 3-5 concrete goals. Everything else flows from there.

Use what already works, customize what matters

Don’t reinvent navigation patterns or form layouts. People know how these work. Save your creativity for the stuff that makes the brand feel distinct—the copy, the visuals, the way things move. That’s where personality lives.

Pick boring, reliable technology

Choose a CMS that the client’s team can actually use. Not the newest, shiniest thing you want to try. If they can’t update content themselves, you’ve failed them. Keep things as simple as possible until there’s a real reason to add complexity.

Don’t skip the basics

Fast loading, works on phones, accessible to people using keyboards or screen readers. These aren’t optional. They’re the foundation. If you’re shipping a site that doesn’t have these sorted, you’re not done.

Make sure they can own it after you leave

Document how to add content. Make sure someone on their team knows how to make basic updates. Set up simple analytics so they can see what’s working. Add monitoring for the critical stuff—like if the contact form breaks.

Where to Use Patterns vs Where to Be Original

Here’s a simple rule I follow:

Keep it standard: Layout grids, form fields, error messages, how links look, spacing between things, mobile breakpoints. Anything structural.

Make it yours: The writing, the story you tell, your photos or graphics, how your buttons look, subtle animations, how you present pricing or services.

Most of the system should feel familiar. The moments that matter should feel like you.

How to Know If It’s Actually Working

Forget pageviews. They don’t matter. Track the actions that matter:

• Are people filling out the contact form?
• Are they booking appointments?
• Are they buying things?

Also pay attention to whether the site is actually fast for real people (not just in testing tools), and whether the client’s team can update content without needing you. If they’re calling you to change a paragraph, something’s wrong.

Warning Signs You’re Overdoing It

• You’ve spent three weeks building a design system for a six-page site
• You’re building a custom CMS when they just need to edit a few pages
• You’re still “perfecting the architecture” instead of shipping actual content

Warning Signs You’re Not Doing Enough

• Images don’t have descriptions for screen readers
• The homepage takes 10 seconds to load
• There’s no way to test changes before publishing them
• If something breaks, there’s no backup

What I Do Every Time Now

Here’s my default approach:

1. Figure out what content types the business actually needs (case studies, services, team bios, whatever makes sense)
2. Ship something lean that loads fast, works for everyone, and they can edit
3. Make it distinctive in the right order: nail the copy first, then the visuals, then add subtle polish if there’s time
4. Watch what actually happens when real people use it, then improve based on that

The point isn’t to pick between “just a website” or “a proper product.” It’s to build the simplest thing that achieves what the business needs—while leaving room to grow when they need it.

How do you handle the tension between getting something live and doing it right? What’s your rule of thumb for when to standardise vs customise?