Web Design & Development in Newcastle & the Hunter

A site is signed off on a designer's monitor, on a fast connection, with the images already cached. That is not where it gets used. It gets used on a phone, on whatever signal is available in a carpark, by someone who has three other tabs open and no particular loyalty to your business. The gap between those two conditions is where a site that photographs well quietly underperforms — and nothing about it shows up in a screenshot, which is why it can go unnoticed for years.

The failures are specific rather than aesthetic. The hero image is a four-megabyte JPEG, so the page is blank for several seconds on a mobile connection. A font loads late and the text reflows, or an ad slot pops in and moves the button somebody was already reaching for. The contact form has no labels, so a screen reader reads it as three unmarked boxes, and a keyboard user cannot reach the submit button at all. None of that is visible to the person who approved the design, because none of it happens on their machine.

The other half of the problem is what the site is being asked to do. On the ABS figures below, just over half of Australian businesses use social media as part of their online presence — real reach, on platforms somebody else owns and can change the rules on without asking. Around a third take orders online, which makes the website the till rather than the brochure. Your website is the part of that presence you actually control, and the standard it has to meet is set by whatever your customer last used, not by what your last website did.

It is the question that decides everything downstream, which makes it worth putting to whoever you are talking to — and worth asking them what would have to be different about your brief for their answer to change. We build both. That is not a boast, it is the reason this section can exist: there is no answer we are commercially obliged to reach, so the comparison below gives each option its genuine advantages rather than setting one up to lose.

Neither column is the right answer. The right answer depends on who edits the site, how much it will change, and what it has to talk to.

The short version is that neither is better. They are better at different jobs, and the job is defined by your business rather than by the technology. A membership site with a plugin ecosystem behind it and a twelve-page site that has to load in under a second on a rural connection are not the same brief, and pretending one platform serves both equally well would be the kind of tidy answer that costs you money in year three.

If you sell online the same logic applies one level down — WooCommerce for catalogue-shaped businesses, a custom checkout on Stripe where a product grid was the wrong shape to begin with. That decision has its own considerations and they are set out on the E-commerce Development page rather than repeated here.

• →Who will actually edit this site — you, a staff member, or us against a monthly support allowance?
• →How often will it change? A site rewritten every month and a site that has been accurate for three years are different purchases.
• →Does anything you need exist as a maintained plugin in one ecosystem and nowhere else?
• →What does the site have to talk to — a CRM, a booking system, an accounting package, a payment provider?
• →Is somebody else likely to work on it later, and how much of a learning curve can they be handed?
• →Are you selling online now, or within the life of this build?
• →How much traffic arrives on a phone, on a connection you would not choose?

Core Web Vitals are three measurements Google publishes as part of its page experience signals, and they are useful well beyond search because each one names a thing a real person notices. Largest Contentful Paint is how long until the main content appears — the wait before there is anything to read. Cumulative Layout Shift is how much the page moves around while it settles, which is the mechanism behind tapping the wrong button because something loaded late and pushed it. Interaction to Next Paint is how long the page takes to visibly respond after a tap, the difference between a menu that opens and a menu you tap twice because nothing happened.

A perfect score in a lab test and a slow site on a real phone are entirely compatible.

The commercial argument does not need a statistic behind it, because the mechanism is enough. Every second of blank screen is another moment in which someone can decide to go back to the search results, and a layout that jumps is a form somebody fills in twice. These are not abstractions about ranking factors; they are the specific ways a visit ends without an enquiry.

Getting them right is mostly a series of unglamorous decisions made during the build. Images in modern formats, sized for the slot they appear in rather than uploaded at whatever the camera produced. Fonts that do not hold up rendering while they download. Space reserved for images, embeds and banners so nothing shifts when they arrive. JavaScript kept small and deferred where it can be. Then there are the scripts added after launch: a chat widget, a tag manager, three tracking pixels. Each one is code we did not write, cannot make smaller and cannot defer safely, so we would rather have that conversation before launch than diagnose it six months later.

It is also worth knowing that a testing tool and a real user measure different things. A tool like Lighthouse runs a simulation on a machine in ideal conditions; the field data Google actually uses comes from real visits on real devices and connections. A perfect score in a lab test and a slow site in the field are entirely compatible, which is why the number to watch is the one collected from people who actually came to your site.

WCAG 2.2 Level AA is the standard we build to, and it is part of the build rather than a line item you can decline. The distinction that matters is timing. Contrast checked while the palette is being chosen, semantic markup written as the templates are written, labels on form fields the first time, a focus indicator designed rather than removed for being ugly — those cost the project close to nothing. The same list applied to a finished site means opening every template again.

The Australian obligation does not come from the guidelines themselves. It comes from the Disability Discrimination Act 1992, which applies to the provision of goods and services, with the Australian Human Rights Commission's web access advisory notes pointing to WCAG as the practical measure. We are not lawyers and none of this is legal advice — if you need a compliance position for a tender or a contract, get it from someone qualified to give one. What we can give you is a site built to the technical standard those positions are written against.

The practical version is less legal and more concrete. A booking form that cannot be completed with a keyboard is not a design flaw, it is a customer who went somewhere else without telling you why. Screen reader users, keyboard-only users, people using zoom, people on a phone in bright sunlight and anyone with a tremor trying to hit a small target are all served by the same work — which is the argument for doing it once, properly, at the start.

If the site in question already exists and was built without any of this, that is a different job: an audit against the specific success criteria, then remediation of what can be fixed and a written statement of what cannot. That work is covered on the Website Rescue & Redesign page.

• →Colour contrast checked in the palette before the design is signed off, not after
• →Semantic HTML and landmark structure, so a screen reader can navigate by heading and region
• →Every interactive path completable with a keyboard, with a focus indicator you can see
• →Form fields with real labels, and error messages that say which field is wrong and why
• →Alternative text written by a person who knows what the image is doing on the page
• →Target sizes and spacing that suit a thumb, not a mouse pointer
• →Focus that is not hidden behind a sticky header — one of the criteria WCAG 2.2 added
• →Video captions and transcripts where there is video to caption

A website is mostly writing. The design decides how it feels, but the words decide whether a visitor understands what you do and whether they trust you enough to make contact — and they are also the raw material search engines and AI answer engines read. Copywriting and content are things we deliver, so a site does not have to sit unlaunched for two months waiting on text somebody keeps meaning to write on a Sunday.

Design a page around copy that does not exist yet and you have designed a shape you then have to fill.

The sequence matters more than it sounds. Design a page around copy that does not exist yet and you have designed a shape that later has to be filled, which is where filler paragraphs and headings nobody needed come from. Write first and the layout can be built around what you actually have to say. If you have a writer already, or copy you are attached to, we work with it — this is not a service you have to buy to get the site.

Branding, logo and graphic design sit here too. Sometimes the reason a site looks dated is not the site: it is a logo that only exists as a low-resolution JPEG from 2011, no consistent colour or type, and photography and graphics that were never made to work together. Rebuilding the site on top of that produces a newer version of the same problem. Where the identity is the constraint, we do that work as part of the project rather than sending you elsewhere for it.

What we do not do is paid media. No Google Ads, no paid social, at any tier. The visibility side of what we offer is organic — the technical foundation from a build done properly, and the search work covered on the Search Engine Optimisation page. If paid advertising is genuinely your next best spend, we will say so rather than subcontract it and take a margin.

A website that does not talk to anything else creates work instead of removing it. An enquiry arrives as an email, somebody copies the details into the CRM, somebody else adds it to a spreadsheet, and at some point in that chain a lead goes missing and nobody can say where. The fix is not a better inbox habit, it is connecting the site to the system your team already works in so the enquiry lands where they are already looking.

In practice that means a handful of integrations, chosen because they remove a manual step rather than because they demo well. Enquiry forms writing into a CRM. A booking flow that checks real availability and writes to the calendar your staff actually use, rather than a request form that starts a phone-tag exchange. A mailing list that receives the subscriber with consent recorded. Payments, where you sell — the mechanics of which belong on the E-commerce Development page. And analytics configured so you can see which pages do the work, with consent handled properly rather than assumed.

This is the part where the IT side of the business shows, and it is a concrete argument for having the website sit with the people who run everything underneath it. An integration is API credentials that have to be stored somewhere sensible and rotated when someone leaves. A contact form is only as reliable as the mail authentication in your DNS zone — SPF, DKIM and DMARC decide whether the notification arrives or is quietly filed as spam, and it is a genuinely common way for a form to appear broken while working perfectly. A booking system holds customer data, which makes it a privacy question as well as a convenience one.

We run email, DNS, backups and security for clients, so those records and those accounts are not somebody else's department. When a website change requires a DNS change, it is made by people who can see what else lives in that zone.

The diagram below is the shape of a build here, and the order of it is deliberate. It starts with the brief and a content audit — what the site is for, and what already exists that is worth keeping. That feeds design and prototype, where the look, structure and behaviour of the site are worked out and put in front of you for review.

Then there is a gate: approval before the build starts. Nothing gets built until the prototype is signed off, because that is the last point at which changes are cheap. Moving a section in a prototype takes an afternoon. Moving the same section once it is built, populated and integrated is a different conversation and a different invoice, and we would rather have the argument while it costs nothing.

After the build, the site is tested for speed and accessibility before it launches rather than after — performance measured, automated accessibility testing run, and the manual checks a scanner cannot do. Launch is the point at which both have passed, not a date in a calendar that arrives regardless. That ordering is the whole reason the gate is drawn where it is.

The last box is the one that is easiest to leave off a project plan: ongoing care. Hosting, certificates, patching, backups and uptime monitoring continue after launch, and the loop running back from care into design is not decoration. What we learn from a live site — which pages get read, where people stop, what the search data says — is what the next round of changes is based on. A site that goes untouched from launch until the next rebuild is not stable, it is just unattended. How that arrangement is packaged, including the monthly support allowance, is set out on the Website as a Service page.