Web Development

This site used to run on Webflow. We moved it onto a static build we control, and the exercise turned up the sort of thing that accumulates quietly on any site nobody is auditing.

There was no sitemap and the robots.txt file was empty. Not one page carried a canonical tag. Five subscribe forms had no destination at all and had been silently discarding anyone who used them. Two links in the navigation led to pages that did not exist. The about page's main heading said "Get in touch".

None of that was visible from the front, and all of it was costing something. It is the honest argument for the service: the problems worth fixing on most sites are not the ones anyone looks at.

The same build this site runs on, which is the most useful thing we can tell you about it — you are looking at the deliverable rather than a portfolio screenshot.

A static site. Pages are built once and served as files, so there is no database to breach, no plugin to patch, no admin login to brute-force, and nothing to go down under load. It is the fastest thing a website can be and the least there is to attack.

A quality gate in the build itself. Twenty-nine automated checks run on every deployment and fail it rather than warn: a missing canonical tag, a duplicate H1, an image without dimensions, a form with no destination, a heading level skipped, an internal link that goes nowhere. The rules cannot quietly stop being followed, because nothing ships when they are not.

Hosting on a global edge network, with certificates and renewals handled, and a deployment history you can roll back to.

Forms that deliver, on an account in your name, with submissions stored so a mail problem cannot lose an enquiry.

The source, in your repository. Every change is a commit with an author and a date, and any of them can be reverted.

Page builders are genuinely good at what they are for. They let someone non-technical change copy without waiting for anyone, and for a business where that matters more than anything else, that is the right trade and you should keep it.

What you give up is control of the output. The markup is generated, the performance ceiling is set by the platform, and the parts that matter for search sit behind whatever settings the builder chose to expose. You also cannot leave easily, because the design and the hosting are the same product.

A static build inverts that. The output is yours, it is fast because there is very little of it, and moving hosts is a deployment rather than a rebuild. The cost is that changing a page is a developer task, not a drag-and-drop one. Neither is the right answer in general. It depends entirely on who needs to change the site and how often, and that is worth settling before anyone builds anything.

Speed is a ranking factor, and well before that it is the reason people leave. Most sites are slow for unremarkable reasons rather than exotic ones.

Images shipped at several times the size they display at. Fonts loaded from three sources when one would do. Analytics, chat widgets, heat mapping and a tag manager, each added for a reason nobody remembers, all executing before anything renders. Whole frameworks downloaded to run a menu.

The work is largely deletion. It is also the least glamorous part of the job and the part with the most reliable payoff.

A good deal of what is sold as search optimisation is repair work on decisions made during the build. Canonical URLs, heading structure, internal links, structured data and a working sitemap are cheap to get right at the start and tedious to retrofit across a site that already exists.

That is the argument for the build gate above. It is not a clever trick — it is the ordinary observation that a rule a person has to remember is a rule that eventually gets forgotten, and that the forgetting is invisible until an audit years later turns up a site with no canonical tags on any page.

We know how that looks from the inside, because it is what we found here.

The same principle we apply to managed IT applies here, and it matters more than it sounds: your domain, your DNS, your hosting account and the source of your site belong in your name.

This is the most common way businesses get stuck. The site was built by someone who registered the domain on your behalf, hosts it in their account, and holds the only copy of the source. Nothing is wrong until you want to change supplier, at which point you find that leaving was made expensive by an arrangement nobody deliberately chose.

It is worth checking who holds those four things for your current site. The answer should take about a minute to establish, and if it does not, that is the answer.

Worth saying plainly, because a mismatch found after signing is expensive for both of us.

It is not a site your team edits themselves. A static build has no admin login, and that is deliberate — it is most of where the speed and the security come from. Changes come to us and we make them, which is part of what the maintenance covers rather than an extra. For a site that changes a few times a month, that is a better arrangement than it sounds: nothing breaks because someone pasted formatting from Word, and the site cannot drift out of the shape it was built in.

If you need to publish several times a week without waiting for anyone, we are the wrong fit and we would rather say so now. That is a content-management product and there are good ones.

It is not e-commerce. Taking payments brings card handling, inventory and a different compliance surface. It is a separate conversation rather than a page count.

It is not a web application. Customer logins, accounts, dashboards and anything with a database behind it is software, with the ongoing burden that implies. A brochure site and an application are different products that happen to arrive through a browser.

It is not brand design from scratch. We will build something clean and coherent, and work within the brand you have. Creating a visual identity, original photography and illustration are a designer's job and we would rather tell you that than approximate it.

Sites decay. Certificates expire, dependencies pick up vulnerabilities, forms stop delivering, a supplier changes an endpoint, links rot as other people reorganise their sites.

The failure that costs most is the silent one. A contact form that stops delivering looks exactly like a quiet month, and nobody investigates a quiet month. We know because we found precisely that on our own site — an inherited form endpoint rejecting every submission, with no account behind it and nobody watching.

So the maintenance question is worth asking before the build question: who is responsible for this in a year, and how would anyone find out it had broken? For an existing managed IT client this is straightforward, because it is the same job as everything else we look after.