Three Things We Prioritise on Every Business Website Build

Every web agency has a list of principles they talk about. Most of them say something like: we're strategic, we care about outcomes, we build for the long term.

These things aren't untrue. But they're also not particularly useful as a description of what actually happens on a project.

What follows is a more specific account of what we actually prioritise when building business websites — and why each of these things tends to matter more than most clients expect when the project starts.

We spend more time on the brief than clients expect

The most common misconception about a website build is that it starts with design.

It doesn't — or at least, it shouldn't. It starts with understanding what the business is trying to do, and whether a website is actually the right solution to the problem being described.

This sounds like standard consulting speak, but the practical version of it is fairly specific: we ask questions about who the website is for, what decision that person is trying to make, and what would need to be true about the website for that person to take action.

These questions sometimes surface a different brief than the one we were given. A client who came in wanting a "full website refresh" might actually need a clearer service page and a better enquiry flow. A client who wants to "showcase more of our work" might actually need a better way to explain what their service involves.

We'd rather figure that out in the first conversation than after the design has been approved.

Usability is treated as a constraint, not a feature

There's a tendency in web design to treat usability as something you add at the end — an accessibility checklist, a mobile review, a check that buttons are big enough.

We treat it differently. Usability is a constraint that shapes decisions from the beginning of the build.

What that means in practice:

Navigation needs to work without explanation. If a visitor needs to read instructions or hover over menus to understand the structure, the structure is wrong.

Mobile isn't a secondary consideration. The majority of initial visits to most business websites now happen on a phone. Designing for desktop first and adapting downward is a guaranteed way to get the mobile experience wrong.

Speed is part of the experience. A beautifully designed page that takes four seconds to load will underperform a plain page that loads in one. We optimise for this throughout the build, not as a final step.

Text has to carry the load. Imagery and layout help, but B2B visitors are reading. The writing has to be direct, specific, and useful — not generic filler that could describe any company in any industry.

None of this is revolutionary. But each of these gets compromised when a build is rushed or when visual ambition outpaces practical judgment.

We build as if we're going to maintain it ourselves

This one changes a lot of decisions.

When you build a website knowing that someone else will manage it in six months, there's a temptation to optimise for the demo — to make it look as good as possible at handover, and let the operational reality sort itself out later.

We try to build against that temptation. Specifically:

The CMS has to be manageable by a non-developer. If updating a service description requires a developer, the CMS is misconfigured. Content management should be something a business owner can do themselves in under ten minutes.

The structure should survive content changes. Pages break when the design assumes a specific amount of text, or a specific number of items in a list. We build layouts that flex — so adding a new team member or a new case study doesn't require redesigning a section.

SEO foundations are built in, not bolted on. Page titles, meta descriptions, heading structure, canonical tags, image alt text — these get set up correctly from the start rather than being retrofitted later. They're also documented so the client knows what they have and why.

Performance doesn't degrade over time. Image handling, caching, and script loading get configured at build, not patched six months later when the site starts feeling slow.

The goal here isn't just to hand over something that works today. It's to hand over something that's still working well in two years.

What this looks like from the outside

Clients sometimes notice that our build process is slower than they expected — particularly in the early stages. More questions, more back-and-forth before design begins.

The projects that go most smoothly tend to be ones where that front-end investment pays off: fewer changes after development starts, fewer surprises at launch, and a site that operates cleanly once it's live.

That's not always the outcome. But it's what we aim for on every project.

---

Webpreme builds custom websites and platforms for businesses in New Zealand and internationally. If you're working through a website project and want to understand what the build process actually involves, we're happy to walk through it.