Web development that stays fast as the site grows

What web development covers here, and what it does not

Design decides what a page should be. Development decides whether it is still that thing on a throttled mobile connection, under a screen reader, with a fourteen-word headline, after two years of edits by people who were not in the original meeting.

Our web development services cover the sites people read and act on: marketing sites, service and sector sites, content platforms, documentation, publisher sites and lead-generation builds. Where visitors sign in and the software has accounts, roles, dashboards and state, that is web application development — a different discipline with a different definition of finished. Where the site takes money for products, e-commerce development brings its own constraints around catalogue, checkout and payment compliance.

Almost everything below is about decisions that are cheap to make at the start and expensive to revisit later. That is most of what this job actually is.

Static, server-rendered or hybrid

This is the first real decision, and it is usually made by habit rather than by argument. It should be made by argument.

Static generation

Pages are built once at deploy time and served as files from a CDN. Nothing computes per request, so the site is fast almost by default, cheap to host, and has a very small attack surface — there is no application server to compromise. The cost is that anything which changes must trigger a rebuild, so a catalogue of two hundred thousand pages that updates hourly is a poor fit. For a marketing site with a few hundred pages and a few edits a day, static is close to a free win, and it is why this site is built in Astro.

Server rendering

Each request is rendered on demand. This is the right answer when content is personalised, when stock or pricing must be current to the second, or when the page depends on who is asking. The cost is real infrastructure: you now have a server that can be slow, can fall over, and must be scaled and patched. Server rendering is not a performance problem in itself, but it moves the performance work from build time to runtime, where it is harder.

Hybrid, and why it is usually the answer

Most real sites are mixed. Marketing pages are static, a search page renders on the server, a dashboard fragment loads client-side after authentication. Modern frameworks — Next.js and Astro among them — support this per route rather than per project, which means the sensible answer is to choose per page rather than adopting one mode as an identity. What matters is that the decision is deliberate and written down. Sites that get slow rarely got slow through one bad choice; they got slow because nobody owned the decision at all.

The front-end standards we hold

TypeScript, and types that mean something. Not because JavaScript is unworkable, but because the person maintaining a content model in eighteen months needs the compiler to tell them what a field can contain.

Semantic HTML before anything else. A <button> is focusable, announced correctly, and works with a keyboard and voice control without a line of script. A <div> with a click handler is none of those things and needs four extra attributes to approximate one. Most accessibility failures we find in audits are recreations of behaviour that browsers already provide.

Progressive enhancement where the platform allows it. Forms submit, navigation works, content renders — then JavaScript improves the experience. Sites built as pure client-side applications fail completely when a single bundle fails to load, and they fail invisibly.

Fewer dependencies, chosen conservatively. Every package is a permanent obligation: a supply-chain risk, a maintenance burden and a possible reason your build breaks in a year. We would rather write forty lines than install a package with three hundred transitive dependencies to avoid them.

Components with all their states drawn. Loading, empty, error and disabled states are where builds usually diverge from designs, because they are the states nobody puts in the Figma file. We ask for them, and where they are missing we specify them rather than inventing them silently.

Choosing a CMS, and why “it depends” is a real answer

There is no universally correct content management system, and anyone who tells you otherwise is describing their own skill set rather than your problem. The variables that actually decide it are: how many people edit, how technical they are, how much page composition they need to do without a developer, and how much of a security surface you are prepared to own.

WordPress remains the default for good reasons. The editor talent pool is enormous, non-technical teams are already trained on it, and the plugin ecosystem solves common problems in an afternoon. Its costs are equally real: a much larger attack surface, plugin conflicts that surface at inconvenient moments, and performance that must be actively defended rather than assumed. Used carefully — a curated plugin list, a properly built theme, managed hosting — it is a perfectly good choice. Used carelessly it becomes the site nobody dares to update.

Headless platforms such as Sanity, Contentful and Strapi separate the content from its presentation. Content becomes structured, reusable across a website and an app, and the front-end can be built in whatever renders fastest. The trade-offs are that you build the editing experience rather than inheriting it, page composition is more constrained by design, and there is a per-seat cost that grows with the team.

Git-based content — Markdown or MDX files in the repository, edited through a lightweight interface — gives you version history, review workflows and zero content-platform cost. It suits technical teams and documentation-style content and suits a marketing team of six non-technical editors very badly.

We recommend one, explain the trade-off we accepted, and note the conditions under which the answer would change. If your team already runs one platform confidently, that competence is a legitimate reason to keep it, and it frequently outweighs a technical advantage nobody in your organisation can operate.

Performance is engineered, not audited

A performance audit at the end of a project tells you what you already lost. The work that matters happens earlier, at the point where someone decides the hero has a background video.

The three Core Web Vitals are the useful shared vocabulary. Largest Contentful Paint should occur within 2.5 seconds, Interaction to Next Paint should be 200 milliseconds or less, and Cumulative Layout Shift should stay at or below 0.1 — each assessed at the 75th percentile of real page loads, split between mobile and desktop. That percentile matters more than the numbers: it means a site that is quick for most visitors and dreadful for a quarter of them is failing, which is exactly the profile of a site tested only on office broadband.

In practice, the recurring causes are unglamorous. Images shipped far larger than the space they occupy. Web fonts that block rendering or swap to a differently-proportioned fallback and shift the layout. Third-party marketing tags added through a tag manager by someone with no visibility of the cost, each competing for the same main thread as your own code. Client-side rendering used for content that could have been HTML.

So we set a budget before the build starts, wire it into continuous integration with Lighthouse CI, and let a regression fail the pipeline. And we monitor field data after launch, because lab scores measure a simulated visit on a machine that is not your customer’s.

Semantic markup does the accessibility and the SEO work at once

Correct document structure is not two jobs. A single heading hierarchy that reflects the actual outline of the page helps a screen reader user navigate by heading, and helps a search engine understand what the page is about. Descriptive link text serves someone tabbing through links out of context and serves the crawler resolving what the destination is. Landmarks, labels and a sensible focus order are the same work as a clean, parseable document.

The floor is WCAG 2.2 at AA: a contrast ratio of at least 4.5:1 for body text and 3:1 for large text and interface components, every function reachable by keyboard, focus never entirely obscured by sticky headers or cookie banners, and adequate target sizes for touch. We test with automated tooling on every build, which catches perhaps a third of real issues, and by hand for the rest — because no automated checker can tell you whether your focus order makes sense or whether your alt text is useful.

Building so search engines can read it

Search engines process JavaScript-heavy pages in stages. Google crawls the HTML first, queues the page for rendering, then indexes what the render produces — and as Google’s own documentation puts it, a page “may stay on this queue for a few seconds, but it can take longer than that”. If your critical content and links only exist after client-side JavaScript executes, you have introduced a dependency on that queue for no benefit. Server-rendered or statically generated HTML removes the question entirely.

The rest of the build-side search work is mechanical and easy to get right if it is planned: one canonical URL per piece of content with consistent internal linking, a redirect map applied at launch rather than after the ranking drop, valid JSON-LD structured data that describes content genuinely visible on the page, an accurate sitemap, and titles and headings that are part of the content model rather than generated from a template pattern. Where the site already earns traffic, this should be run alongside a technical SEO workstream from the beginning of the project rather than as a launch-week checklist.

Integrations, and the failure nobody plans for

Most sites of any size talk to something else: a CRM, a booking system, a payment provider, a mailing platform, an ERP, an analytics stack. Building the happy path is straightforward. What separates a robust build from a fragile one is what happens when the other side is slow, rate-limited or down.

An enquiry form that posts directly to a CRM and shows an error when that CRM times out has just thrown away a lead. The same form that writes the submission to its own store first, then syncs, loses nothing and can be retried. We build integrations with explicit timeouts, retries with backoff, idempotency where a duplicate write would cause harm, and a visible record of what failed. Credentials live in a secret store rather than in the repository, and every integration is documented with its data mapping so that the next person can see what the site believes a lead actually is. Getting the measurement side of that right is often a conversation with our data and analytics team rather than a purely engineering one.

Hosting, deployment and the pipeline

Deployment should be boring. A change is committed, continuous integration runs the type checks, tests, accessibility checks and performance budget, a preview environment appears for review, and a merge ships it. That takes a day or so to set up and pays for itself the first time it catches something.

We use GitHub Actions for the pipeline, and match the host to the architecture rather than to preference: static and hybrid builds on Vercel, Netlify or Cloudflare; WordPress on managed hosting with its own caching and staging. Whatever the platform, three things are non-negotiable. Every account is registered to you. Every deployment can be rolled back. And backups are verified by actually restoring one, because an untested backup is a belief, not a plan.

Security, and the honest part about plugins

Web security for a content site is mostly discipline rather than cleverness. The OWASP Top Ten is the standard reference for the risk categories worth designing against, and most real incidents on small and mid-sized sites come from a short list: an outdated plugin or dependency with a known vulnerability, a weak or reused administrator credential, an unvalidated file upload, or a form endpoint with no rate limiting.

The measures that address them are equally short. Keep dependencies patched and remove the ones you are not using. Enforce multi-factor authentication on every administrative account. Serve a Content Security Policy, which limits what injected script can do if something does get through and is one of the few controls that helps after a failure rather than before it. Validate input server-side regardless of what the client already checked. Put a web application firewall in front of anything with a login.

The inconvenient part: a plugin-heavy site is a security posture you are choosing, not an accident. Every plugin is code from a third party running with full access to your database. That is a defensible trade if the plugin list is short, curated and maintained. It is not defensible if nobody can say why nineteen of them are installed.

Testing, and what launch day should feel like

We write end-to-end tests in Playwright for the journeys that make you money — the enquiry form, the search, the checkout step, the sign-up — because those are the paths where a silent regression is expensive. Alongside that: keyboard and screen reader passes on interactive components, a real-device check across the browsers your analytics say your visitors actually use rather than a generic matrix, and content stress tests with the longest and shortest realistic values.

Launch day should be uneventful. Redirects mapped and tested, monitoring live before the DNS change rather than after, a restore rehearsed, and a documented path back to the previous version. Where the site already ranks, Google recommends keeping redirects in place for at least a year, because signal transfer takes time and pulling them early is a self-inflicted wound.

What makes a build cost more or less

We do not publish a price, because the drivers vary more than any headline figure would suggest. The ones that genuinely move it are: the number of distinct templates rather than the number of pages; whether a design system exists or must be built; how many integrations there are and whether their APIs are documented and stable; whether content is migrated automatically or by hand; how many editorial roles and permission levels the CMS needs; the browser and device matrix in scope; and whether the site must be delivered in more than one language.

Two things reliably cost more than clients expect. Content migration from an unstructured legacy site is slow work that resists automation. And approval structures — the number of people who must sign off, and how quickly they do — shape a schedule more than any technical decision. We scope against those variables in writing before quoting, and we would rather show you a wide range with its reasons than a precise number that is fictional.

Where this sits alongside our other work

Development rarely arrives on its own. If the site needs to be designed as well as built, that is web design, and having both under one roof mostly saves you the detail loss that happens at handover. If people sign in and use the thing repeatedly rather than reading it, the discipline you want is product interface design feeding an application build rather than a website one. And if the current site already earns organic traffic, the migration needs planning from day one rather than from launch week.

If you are not sure which of those you need, tell us what the site has to change and we will say which — including when the answer is less work than you were expecting.