Newton-in-Cartmel Village Hall.
A modern community website that a non-technical committee can run for years without ever touching code.
A site that had grown features instead of being designed.
Newton-in-Cartmel Village Hall serves six small communities: High & Low Newton, Ayside, Barber Green, High Cark, and Field Broughton. Its previous website ran on Brizy Cloud, a drag-and-drop builder that had become genuinely limiting, and the committee had lost administrative access to their own domain along the way.
The deeper problem was that the old site had accumulated features rather than being designed as a whole. Events were written up by hand in one place, a Google Calendar existed separately, documents and newsletters lived in scattered downloads, and there was no clear way for a volunteer committee to keep any of it current without calling a developer. The brief was simple to state and harder to deliver: a modern, attractive site the committee could realistically maintain themselves, indefinitely, without learning to code or manage a CMS.
Build around what they already do.
This is the part of the project that mattered most, and it shaped every other decision. Most website rebuilds solve "how does the client update this?" by adding a content management system, a WordPress admin, a headless CMS, a custom dashboard. That's the default answer, and for a lot of clients it's the right one. For NCVH, it would have been the wrong one. The committee is a small group of volunteers with limited spare time and no interest in learning new software. Any system that asked them to log into an unfamiliar admin panel, however simple, was a system that would eventually stop being updated.
So the real question wasn't "what's the best CMS for this?" It was: what does this committee already do, every week, without being taught? The answer was Google Calendar, Google Drive, and email. That became the entire foundation.
Events run on the calendar they already keep. Adding an event to "What's On" means opening Google Calendar and adding an event, exactly as the committee already did before the new site existed. The website reads that calendar live via the Google Calendar API and turns each entry into a styled noticeboard card automatically, no website login, no second system, nothing to remember to update in two places. A simple [Music] Event name convention in the title lets them tag events by category without ever seeing a "category" field in any admin screen.
Documents and newsletters live in folders they already understand. Rather than a media library or upload form, the site simply displays the contents of two Google Drive folders. Drop a PDF into the public "NCVH Documents" folder, and it appears on the website's Documents section within minutes, no upload dialog, no file manager, no code. A second, separate "NCVH Committee" folder, kept intentionally distinct from the public one, powers a password-protected internal page, so nothing private ever risks ending up in the public folder by mistake.
Bookings stay honest about what they are. Rather than building, or worse, faking, real-time booking, hall hire requests are a structured form that emails the committee directly. A human checks the calendar and replies to confirm. This wasn't a shortcut, it was a deliberate choice: a small volunteer-run hall doesn't want strangers auto-booking slots with no oversight, and pretending otherwise creates more problems than it solves.
The one unavoidable technical step was handed over as a favour, not a requirement. Creating the Google Calendar API key needed a few minutes in Google Cloud Console, the single piece of this system that looks like "real tech setup." Rather than teaching the committee to do it, that step was simply done for them, once, as part of delivery. Everything downstream of it is plain Calendar and Drive use.
The result: three tools the committee already had muscle memory for became the entire content management system. Nothing new to learn, nothing to forget how to use six months later.
The logo and the newsletter needed fixing too.
Partway through the project, it became clear that two things outside the original brief were quietly working against everything else that had been rebuilt: the hall's existing logo, and its newsletter format.
The version of the logo in circulation was a low-resolution, dated graphic that didn't hold up next to the new design. A crisp, properly transparent version was produced to match the site's visual language, and rolled out consistently across the header, footer, and browser favicon. The existing newsletters were plain email exports: grey "view in browser" bars, a fuzzy old logo, no visual connection to the new site at all. A new Word-based template was designed to match the site's colours and typography exactly, with built-in instructions so the committee could keep producing newsletters themselves every month without any design help.
Neither was part of the original agreement. Both were delivered because a client-facing redesign is only as strong as its most visible weak point, and for a small community organisation, the logo and newsletter are often what people see more often than the website itself.
The plan changed twice before the final build. Both times, for the better.
An early prototype explored a full custom WordPress theme, in case a familiar CMS admin was the better fit for this client. Once the real requirement, just events and bookings, nothing more, became clear, the project moved to a lean static site with live integrations, avoiding the ongoing overhead of a CMS, a database, or hosting costs beyond a free tier.
A design review pass caught real issues before launch: an internal "how to update this" note that had accidentally been left visible to the public, a booking form with too few fields to be genuinely useful to the committee, and an inaccessible mobile navigation menu, all fixed before hand-off. A written admin guide and a matching newsletter template, built in Word, not requiring any design software, were handed over alongside the site, so the "no code" principle extended to documentation too: the guide itself needs no technical skill to read or use.
A site the committee can run for years.
The site is now live, with every integration connected and tested against the real accounts. Events update themselves the moment the committee touches the calendar they already use. Documents and newsletters update themselves the moment a file is dropped into the right Drive folder. Booking requests arrive by email, with a human confirming every one before it's real. Committee-only material sits behind a simple password, backed by its own private Drive folder.
No database, no CMS licence, no admin logins to lose track of, and hosting on a free tier throughout. The site is genuinely usable today, and the honest measure of success will be whether the committee is still updating it themselves without help in a year's time, not a metric available yet, but the entire design was built around making that outcome likely rather than hoping for it.