Architecture

Matley Dental

A solution-architecture summary — how the system is designed, and why. Verified from the source code.

Type of system: Static marketing site
Users: Prospective and existing patients (mostly on phones)
Hosting: United Kingdom
Main stack: Next.js (static) — no backend, no database
Status: Live
Built for: Client — a dental practice

The problem

A dental site has two jobs that pull against each other: make booking effortless for people who already want an appointment, and reassure the ones still deciding. Slow pages, hidden prices or a contact form instead of a phone number lose exactly the patients who were closest to booking.

How it fits together

Users

Prospective patients (mostly on phones)

Front end

Next.js 16 (static, App Router)

Backend / API

None — a small Node process serves pages and resizes images

External services

portal.dental — outbound booking link

Patients, usually on phones, load pre-rendered pages served by a small Node process behind nginx. There is no database and no user accounts. Booking is an outbound link to the practice's existing portal.dental system — no data is exchanged.

Tech stack

Front end

Next.js 16 (App Router), React 19, TypeScript
Tailwind CSS v4, self-hosted fonts
next/image (AVIF/WebP)

Backend

None — pages are pre-rendered; a Node process serves them

Database

None

Hosting

United Kingdom
Linux VPS, nginx, Let's Encrypt, systemd; deployed via Azure DevOps over SSH

Third-party

portal.dental — outbound booking link only

Key design decisions

Static, no CMS, no plugins

Why: A marketing site with no logins or user data doesn't need a database or WordPress. Pre-rendering every page makes it fast and leaves almost nothing to attack.

Trade-off: Content changes are code deploys rather than a CMS edit.

Book through the practice's existing portal

Why: Don't rebuild clinical booking — hand off cleanly to portal.dental.

Trade-off: Booking lives off-site, by design.

Prices in the open

Why: Publishing fees cuts friction and no-shows and builds trust before the first call.

Trade-off: None — a deliberate choice we recommended.

Structured data, but no self-serving review markup

Why: JSON-LD for the practice, FAQs and procedures helps search understand the site; we deliberately omit star-rating markup.

Trade-off: Forgoes star snippets in results, keeps it honest.

Security & data protection

Hosted in the United Kingdom.
TLS 1.3 over HTTP/2, with HSTS (two years, preload), nosniff, Referrer-Policy and X-Frame-Options.
No user input, no accounts and no database — there is almost nothing to attack.
No secrets in the repository; deploy credentials live in the CI service connection.
No cookies beyond a local theme preference, and no trackers.

Built to hold up

Performance: Every page pre-rendered; images served as AVIF/WebP via next/image; fonts self-hosted.
Availability: A single UK host, health-checked on deploy, keeping the last five releases for instant rollback.
Scalability: Static pages scale trivially behind nginx.

Results

PageSpeed (mobile): 93 / 100.

What we'd do next

Add a Content-Security-Policy header.
Add lightweight, privacy-friendly analytics so the practice can see what patients look for.
Consider on-site booking if the practice ever moves off portal.dental.

Back to the Matley Dental case study Visit matleydental.co.uk