Built So the Practice Never Has to Call Me

Referral-led practices don't need to be found. The work arrives from surgeons and clinics, and it has done for years. What they do need is to survive being looked up, usually by a patient who has been handed a name and is checking it before a procedure. When I started, Ravenscroft Anaesthetic Services had nothing to find at all.

So the goal I set was specific: once the site was live, the practice should never have to book me in to change a link. Everything below follows from that.

The model is deliberately shallow. Pages are built from blocks. Navigation and footer links are their own entries rather than hard-coded markup. Rich text carries inline buttons and an embeddable contact form, which means a call to action can sit inside a sentence without a developer adding a component.

Nothing in the model is specific to Ravenscroft, and that is the point. The changes this practice actually makes are link edits, new paragraphs and the occasional new page. Those are the three things the model covers.

The editor is built for someone who doesn't normally manage a website. Blocks are dragged onto a page and edited against a live preview, and nothing is public until it's explicitly published. The practice can draft something, look at it, and change its mind before anyone else sees it.

Deployment is on AWS via OpenNext. Pages are server-rendered on demand, then stored in S3 and cached in CloudFront. Once a page has been generated there are no further Lambda invocations, which is what keeps a site this size cheap to run. Content is revalidated instantly when it's updated, so patients get the current information at the point they need it most.

Media is served straight from the private S3 bucket through a CloudFront behaviour, evaluated ahead of the default route. Without that, every image byte proxies through the Next.js server Lambda via Payload's file endpoint, and you end up paying Lambda time to move bytes CloudFront would happily serve on its own.

An edit has to reach a patient in seconds, which is harder than it sounds. A deployed site of this shape has two caches: finished pages sit in an S3 bucket, and CloudFront keeps its own copy in front of them. Clear one and the other carries on serving yesterday's page.

The first version did the obvious thing. Work out which pages the edited content appears on, then clear only those. That relies on a Next.js feature called cacheComponents, and cacheComponents turned out to break the Payload admin panel: it loads blank. The admin panel is the whole point of handing a site over, so it won.

Without it, targeted clearing fails silently, which is worse than failing loudly. So publishing now clears the cache completely. That's heavy-handed and it's deliberate: at this size it costs nothing measurable, and I'd rather be blunt than wrong. Payload is targeting support for this in v4, so the precise version goes back in then. Because the interface never changed, that's one module to swap and no call sites to touch.

Enquiries come in through a handmade call to action and a custom contact form. The form is embeddable in paragraphs and text, so the site owner can invite people to get in touch in their own words, and it can sit on more than one page without a developer placing it.

Since handover in August 2025, the site has been fully managed by Ravenscroft Anaesthetic Services. 24 published edits, none of them mine. They draft and publish pages, trial new content and update links to external partners without involving me at all.

If there's one lesson I'd take from this build, it's that a site that needs its developer for a link change hasn't really been handed over. That was the goal from the first sketch, and the content model was shaped backwards from it.