Website Development

Building on foundations that last

A website is a piece of software. It has dependencies that age, integrations that change, and an attack surface that grows every time something is bolted on. Most of the trouble small businesses have with their websites — the sudden breakage, the hacked pages, the mysterious slowdown — traces back to how the site was built rather than how it was designed.

We build with a small, deliberate stack: Next.js with TypeScript, content stored as Markdown in your own Git repository, and hosting on a global edge network. Pages are generated at build time as static HTML wherever that is possible, which is nearly always. There is no database to be breached, no plugin ecosystem to be patched every fortnight, and no server executing code on every request.

The commercial effect is straightforward. Pages arrive quickly, running costs are close to zero, and the routine maintenance burden is small enough that we can include it in a sensible monthly fee rather than billing you every time something needs attention.

What "statically generated" means for you

When a page is statically generated, the HTML is produced once when the site is built and then served directly from a location near your visitor. Nothing is assembled while they wait.

In practice this means:

• Speed that holds up. There is no database query, no template rendering and no plugin chain between the request and the response. A cached HTML document is about as fast as the web gets.
• Reliability under load. A mention in the local press or a busy period does not slow the site down, because serving the ten-thousandth copy of a file costs the same as serving the first.
• A much smaller attack surface. There is no login form on the public site, no database credentials in play, and no code being executed per request for an attacker to influence. This is a large part of our security approach.
• Cheap hosting. Static files on a free tier, rather than a virtual server that needs patching and paying for.

Where genuinely dynamic behaviour is needed — form submissions, for instance — we use server-side functions that run only for that specific action and nowhere else.

Content management without the baggage

Clients reasonably want to edit their own content. That does not have to mean a database-backed CMS with a plugin directory.

We use Decap CMS, a Git-backed editor. You sign in with GitHub at /admin, edit your pages, articles and FAQs in a friendly interface, and press save. Behind the scenes each save commits Markdown to your repository, which triggers a rebuild and republishes the site a minute or two later.

The advantages compound over time:

• Every change is a commit, so you have a complete, attributable history and can undo anything
• Content is plain Markdown — readable in fifty years, portable to any system
• There is no CMS licence, no per-editor fee and no upgrade path to worry about
• The editor is not part of your public website, so it cannot be attacked as one

Frontmatter is validated when the site builds. If a required field is missing or a description is too long for a search result, the build fails with a clear message naming the file rather than quietly publishing something broken.

Forms and CRM integration

For most of our clients the contact form is the single most valuable thing on the website, so it gets treated accordingly.

Validation runs twice: in the browser for immediate, accessible feedback, and again on the server, because client-side validation is a convenience and never a control. Both use the same schema, so the rules cannot drift apart.

Submissions are handled by a server action rather than a public API endpoint, which means the framework verifies the request origin and cross-site request forgery is handled without extra code. Spam is filtered with a honeypot field, a rate limit and reCAPTCHA v3 — chosen over a checkbox challenge because it asks nothing of the user and therefore creates no accessibility barrier.

Enquiries are then pushed into your CRM. We write to Zoho CRM as standard, creating both a lead and a contact, through a service abstraction rather than calling the API directly from the form. If your CRM changes, one file changes. If the CRM is unreachable, the enquiry is retained and the visitor still gets a proper confirmation instead of a stack trace.

Search engines and structured data

Technical SEO is part of the build, not a later add-on:

• Server-rendered HTML, so crawlers see the content without executing JavaScript
• Canonical URLs on every page, and one URL per piece of content
• A sitemap and RSS feed generated automatically from the content, so they cannot go stale
• Structured data for the organisation, the local business, articles, breadcrumbs and FAQs
• Open Graph and Twitter/X card data, with a generated share image
• An llms.txt file describing the site for large language models, which increasingly matters for how businesses are summarised by AI assistants

None of that will make a thin site rank. It removes the technical obstacles so that genuinely useful content has a fair chance.

Testing before launch

Every build is checked on real devices rather than only in a desktop browser at 1440 pixels. That means a small Android phone as well as a recent iPhone, and a genuine 320-pixel viewport, because there are still people using older devices with the text size turned up.

We also test:

• The entire site with a keyboard alone, checking focus order and that nothing becomes unreachable
• Key journeys with a screen reader, particularly the contact form and navigation
• Core Web Vitals — largest contentful paint, cumulative layout shift, interaction to next paint
• Every form's error and success states, including what happens when an integration fails
• All old URLs, so nothing that currently ranks is lost to a 404 at launch

Launch and afterwards

Launch is a checklist, not an event: DNS and certificates, redirects from the old site, search console verification, sitemap submission, then two weeks of watching the logs and vitals for anything the tests missed.

After that, most clients move onto a managed plan covering hosting, updates, monitoring and a monthly allowance of changes. Some prefer to take the keys and run it themselves, which is entirely possible — the handover documentation explains the deployment process, the environment variables and the content model.

If you have a project in mind, or an existing site that has become difficult to change, tell us about it or call 01420 446331. We will tell you what we would build, what it would cost and how long it would take, in writing, before you commit to anything.