The Technology Behind the Work

A static site is one where every page is built into finished HTML when the site is published, instead of being assembled by a server on every visit. The browser receives a complete page straight away, with no database query and no rendering step to wait for.

For a business that means three things. It is fast, because the page is already made, which helps Core Web Vitals and search ranking. It is cheap to run, because serving files costs a fraction of running an application server. And it is hard to break into, with no database to compromise, no admin login exposed to the internet and no plugins to keep patched.

Anything dynamic (live stock levels, a customer account area, a booking calendar showing real availability) still needs a service behind it. So most of my builds are static pages with specific dynamic pieces added where needed. This website is built that way: every page is prerendered at build time.

Website builders do their job well. Wix plans run from around £9 to £119 a month and Squarespace from around £12 to £79 a month, both with templates, hosting and a visual editor included. If you need something online this week, are comfortable building it yourself, and the site is a simple shopfront, a builder is a reasonable choice.

The costs build up over time. Subscriptions continue for as long as the site exists and tend to rise. Templates limit what you can do, so the site looks like every other business on that template. Performance and accessibility are largely out of your hands, and both affect search ranking. Apps and add-ons are billed separately, often £5 to £30 a month each. And the site cannot move: a Wix site cannot be taken to another host.

WordPress sits in between. It is flexible and portable, but it is an application that needs maintaining. Core, theme and plugin updates have to be applied, and out-of-date plugins are the most common way into a small business website. Either you do that work every month or you pay somebody to.

A custom build starts from £100 and takes a little longer. You get a site designed for your business, built to accessibility and performance standards you can check, with no subscription attached to the site itself. For a business where the website brings in work, that usually pays for itself. If you only need a placeholder online by Friday, a builder is the better fit.

Pricing →

Many applications need a backend API to handle data, authentication, payments and third-party integrations. I design and build REST and GraphQL APIs with OpenAPI contracts, semantic versioning and documentation. REST endpoints follow standard HTTP status codes (200 OK, 201 Created, 400 Bad Request, 401 Unauthorized, 404 Not Found, 500 Internal Server Error) and use HTTP verbs (GET, POST, PUT, DELETE) consistently.

Authentication uses established protocols: OAuth 2.0 for delegated access and JWT (JSON Web Tokens) for stateless session management. Rate limiting protects APIs from abuse, and CORS policies are configured correctly for cross-origin requests. Backend services are built in .NET (C#) or Node.js depending on what the project needs, both strongly typed and both with mature frameworks behind them.

Data persistence uses relational databases (SQL Server, PostgreSQL, MySQL) with normalised schema design, appropriate indexing, and transactional integrity. Third-party integrations include payment gateways (Stripe, PayPal), booking systems (Booksy, Square), CRM platforms (HubSpot, Zoho), and email services (Mailchimp, SendGrid). Each integration is abstracted behind a clean interface so dependencies can be swapped without rewriting application logic.

REST and GraphQL solve the same problem in different ways. REST gives you one URL per resource and is simpler to cache, debug and document, which makes it the right default for most business websites and integrations. GraphQL gives the client a single endpoint and lets it request exactly the fields it needs. That helps when one screen pulls from many sources or mobile bandwidth is limited, at the cost of more complex caching and a steeper learning curve. For a small business site with a contact form and a booking integration, REST is almost always the better choice.

Every site I build targets WCAG 2.2 Level AA. It is the standard referenced by UK accessibility obligations and the level most commercial and public sector contracts ask for, covering keyboard operability, screen reader support, colour contrast and error handling. Accessibility is designed in from the first decision, because retrofitting it before launch is where the cost lands. WAI-ARIA attributes (aria-label, aria-labelledby, aria-describedby, aria-live, role) are used sparingly, to add meaning where HTML alone falls short.

Keyboard use is tested on every build: each interactive element has a visible focus indicator, focus order follows reading order, and there are no keyboard traps. Screen reader testing uses NVDA (Windows) and VoiceOver (macOS and iOS) to check announcements, landmark navigation and live region updates. Colour contrast meets or exceeds WCAG AA ratios (4.5:1 for normal text, 3:1 for large text), and colour is never the only thing carrying information. For people who prefer reduced motion, the prefers-reduced-motion media query switches animation off.

Forms are built for clarity and error recovery. Labels are associated with their inputs, validation errors are announced to screen readers and linked with aria-describedby, and error messages say how to fix the problem. There is a legal side too: the Equality Act 2010 applies to businesses providing services to the public, and public sector bodies must meet the Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018. Commercially, more people can use the site, everyone finds it easier, and search engines reward well-structured markup.

WCAG 2.2, published in October 2023, adds nine success criteria on top of WCAG 2.1 rather than replacing it, so a site that meets 2.2 Level AA also meets 2.1 Level AA. The additions mostly concern focus visibility and appearance, dragging alternatives, target size (a minimum 24 by 24 CSS pixels for interactive controls), consistent help placement, and reducing the cognitive load of authentication and redundant data entry. If a contract or tender asks you to meet "WCAG 2.1 AA", building to 2.2 satisfies it with room to spare.

Every project is designed for UK GDPR compliance from the outset. Personal data processing rests on a lawful basis (consent, contractual necessity, legitimate interests, legal obligation), documented clearly in the privacy policy. Data minimisation means collecting only what is necessary. Purpose limitation keeps that data to the stated purpose, and storage limitation sets the retention period after which it is securely deleted. Consent for analytics and marketing cookies is obtained explicitly through opt-in banners under PECR (Privacy and Electronic Communications Regulations), and a user can withdraw that consent at any time, which triggers immediate deletion of tracking cookies.

Analytics are configured with privacy in mind. Google Analytics 4 runs with IP anonymisation, sensitive data is kept out of event parameters, and retention periods are set appropriately. Where a privacy-focused alternative suits the project better, I will recommend it. Data subject rights under UK GDPR (subject access requests, rectification, erasure, data portability and objection) are supported by clear processes and the technical work to back them. The ICO publishes the regulatory guidance, and I help clients work out what it means for them as data controllers.

Data in transit is encrypted using TLS 1.2 or higher (HTTPS everywhere), and sensitive data at rest is encrypted using industry-standard algorithms (AES-256). Where data is hosted, I prefer UK or EU data residency to avoid the complications of international transfers, which is straightforward on Microsoft Azure using the UK South or UK West regions. Backups are encrypted and tested regularly, and disaster recovery procedures are written against defined recovery time objectives (RTO) and recovery point objectives (RPO).

This information is provided for general guidance and does not constitute legal advice. Consult a qualified data protection solicitor for specific legal requirements.

Hosting is cloud-first. Microsoft Azure provides scalable infrastructure with global edge delivery through Azure Static Web Apps, Azure App Service and Azure CDN. Static sites are deployed to the edge network and served from the location closest to each visitor, which keeps load times down. HTTPS is on by default, with certificates renewed automatically through Let's Encrypt or Azure-managed certificates.

Development, staging and production environments are kept separate using Azure resource groups and deployment slots, so changes are tested before they reach the live site. Auto-scaling absorbs traffic spikes. Uptime is monitored with Azure Monitor and Application Insights, with alerts for slow responses, errors or downtime. Costs are kept in check through resource tagging, budget alerts and right-sized compute and storage. For a small business with predictable traffic, cloud hosting can be inexpensive.

Infrastructure as code is used where the project needs it, defining resources in Bicep or Terraform so deployments are reproducible and changes are version-controlled. Backups run automatically and restores are tested, with rollback in place if a problem appears after release. Azure's UK regions (UK South, UK West) keep data inside the UK, which simplifies GDPR compliance and meets data residency requirements.

Docker packages an application and its dependencies into an image that runs the same way in development, staging and production. Multi-stage builds discard everything the compile and test stages needed, so only the final runtime image is deployed. A smaller image means a smaller attack surface.

Images are pushed to a container registry (Azure Container Registry or Docker Hub) with version tags, so a failed deployment can be rolled back. Base images are kept up to date with security patches, and vulnerability scanners (Trivy, Snyk, Azure Defender) flag known CVEs in dependencies. Dependency installation is cached separately from application code, so builds skip downloads when nothing has changed.

CI/CD pipelines run each change through defined stages: lint checks for code style, type checks for TypeScript, unit and integration tests, an optimised build, and deployment to the target environment. Preview deployments let you review changes before anything is merged, and if a release introduces a bug, the pipeline can revert to the last working version quickly.

Performance is measured with Google's Core Web Vitals. Largest Contentful Paint (LCP) measures loading and should be under 2.5 seconds. Interaction to Next Paint (INP) measures responsiveness and should be under 200ms. Cumulative Layout Shift (CLS) measures visual stability and should be under 0.1. These numbers affect user experience, conversion rates and Google rankings, so every project is built to meet the Good thresholds.

Images are served in modern formats (AVIF with WebP fallback) and sized for each screen with srcset and sizes. Offscreen images load as the visitor scrolls, which reduces the initial page weight. Fonts are self-hosted, subset to the characters needed and use font-display: swap so text is never invisible. Critical CSS is inlined so the top of the page renders immediately.

JavaScript is split by route, so visitors only download the code for the pages they open. Third-party scripts such as analytics load asynchronously so they do not block the page. Static assets are cached for a year with hashed filenames, so returning visitors load pages almost instantly.

Technical SEO is what lets search engines crawl, index and rank your content. Semantic HTML structure with a correct heading hierarchy (one h1 per page, logical h2-h6 nesting) tells them what matters and how it relates. Metadata covers title tags (55-60 characters), meta descriptions (150-160 characters) and Open Graph tags for rich social media previews. JSON-LD structured data (Schema.org markup) adds explicit semantic context: LocalBusiness, Product, Article, BreadcrumbList and FAQPage schemas help search engines identify content types and show rich results in SERPs.

XML sitemaps list every page for crawlers, and robots.txt controls access to specific paths. Canonical URLs prevent duplicate content problems, and 301 redirects guide search engines when URLs change. Prerendering delivers complete HTML to crawlers on the first request, which is what makes JavaScript applications reliably indexable.

For businesses that serve more than one country or language, internationalisation (i18n) with hreflang tags signals the regional and language variants to search engines, which heads off duplicate content problems.