Newton-in-Cartmel Village Hall.
A modern community website, built around tools the committee already uses every day. Nobody has to call a developer for a routine update again.
A site that had grown features instead of being designed.
Newton-in-Cartmel Village Hall serves several small communities around the hall. These include High and Low Newton, Ayside, Barber Green, High Cark, and Field Broughton. Its previous website ran on a drag-and-drop builder that had become genuinely limiting. The committee had also 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 manually in one place. A Google Calendar existed separately, and documents and newsletters lived in scattered downloads. There was no clear path for a non-technical 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, with zero coding knowledge.
Built around what they already know how to use.
Rather than reaching for a traditional CMS, which still means learning an admin panel, I built the whole architecture around a different question. What does this committee already use every day, regardless of the website? The answer was Google Calendar and email.
Events are never written twice. The committee adds an event to their existing Google Calendar exactly as they always have. The website reads that calendar automatically, turning each entry into a styled event card. No website login, no second system to update. A simple prefix convention in the event title lets them categorise events without ever seeing a "category" field in any admin screen.
Instant real-time booking risks double-bookings, and isn't what a small venue actually needs. So a structured enquiry form emails booking requests straight to the committee instead. They check the calendar themselves and confirm by reply, so a real person stays in the loop. The design itself uses real photography of the hall: exterior, interior, kitchen, and step-free entrance. It's set against a Lake District-inspired palette, with serif headings for character and a clean sans-serif for everyday readability.
A facilities section that answers before it's asked.
A facilities section is built from a real inventory rather than marketing copy. Hall dimensions, seating and table counts, kitchen equipment, and accessibility information all get covered. That answers the questions that generate the most enquiry emails, before anyone has to ask them. A password-gated committee area, separate from the public site, gives committee members a single link to shared documents stored in Google Drive. Again, no new system to learn.
Built through honest pivots, not a fixed plan.
An early prototype explored a full custom WordPress theme, in case a familiar CMS admin was actually the right fit. Once the real requirement, just events and bookings, nothing more, became clear, the project moved to a leaner static site. That avoided the ongoing overhead of a CMS or database entirely.
A design review pass caught real issues before launch. An internal "how to update this" note had accidentally been left visible to the public. Booking form fields were too sparse to be useful to the committee, and the mobile navigation had accessibility gaps. All of it got fixed before hand-off, not after.
A site the committee can run for years.
Events update through the calendar they already use. Bookings arrive by email, confirmed by a real person. Documents live in a Google Drive folder behind a simple committee-only page. Everything else, the design, the facilities information, the photography, stays mostly the same. It only needs revisiting occasionally, not edited day to day.
Hosting runs on a free tier, with no database, no CMS licence, and no recurring software cost beyond the domain itself.