Inspired Villages
A flat-file CMS for a national later-living brand: a component-driven site editors build like Lego, a decade of content migrated out of Drupal, and the performance work to make it all fast at scale.

A new home for a national later-living brand
Inspired Villages is one of the UK's leading operators of later-living retirement communities, with villages across the country offering homes to buy and rent, restaurants, wellness facilities and a full calendar of resident events. Their existing website ran on an ageing Drupal 9 platform that had become slow to edit, hard to extend and expensive to maintain.
Working to designs by Jane Richardson and delivered with Apogee Creative, I built the replacement: a content-driven website on Statamic, where the marketing team composes every page from a library of reusable building blocks, all of their legacy content was migrated across automatically, and the whole thing is fast enough to handle a property catalogue running into the thousands.
The site launched in 2026 and replaced the legacy Drupal estate entirely.
More than a redesign
The brief, a detailed functional specification covering more than forty components, pages and forms, called for a platform that could:
Empower a non-technical team
Let the marketing team build and edit pages freely, without a developer in the loop for every change.
Carry years of legacy content forward
Hundreds of blog posts, resident stories, FAQs, team profiles and more than a thousand individual property listings, out of Drupal without manual re-keying.
Stay fast under weight
A retirement operator's site is content-heavy by nature: village pages, property catalogues, event feeds, story archives. Done naively, that kind of site buckles.
Integrate with the wider business
The Sherpa sales tool the teams live in, the PageUp careers platform, cookie consent, analytics and a suite of enquiry forms feeding leads to the right village.
A content engine the marketing team actually enjoys using

A component-driven CMS
The heart of the site is a page builder. Rather than fixed page templates, editors assemble pages from a library of around thirty-five reusable components: hero carousels and video heroes, image-and-text blocks, feature grids, process steps, blog and story carousels, an interactive village map, property showcases, careers listings, CTA banners and more.
Every component is defined once, given realistic sample content, and rendered into a preview image that appears in the CMS itself, so an editor choosing a block sees exactly what it will look like before they add it. Components with genuinely different layouts generate an animated preview that cycles through each variant. The previews are produced automatically by a headless-browser screenshot pipeline, so they never drift out of sync with the real components.
The result is a system where the marketing team builds pages like Lego, and every page stays on-brand by construction.









A sample of the ~35 page-builder components, each rendered to a preview that appears inside the CMS so editors pick blocks by sight.
A token-driven theme system
Inspired Villages is not one brand colour but several: a family of village identities sitting under the parent brand. So rather than hard-code colours into each component, I built the whole front end on design tokens and a theme system layered on top.
Every component can be assigned one of four colour themes, and the entire block recolours itself: buttons, highlights, accent text, background tints, focus states, all of it. Underneath, each theme simply remaps a small set of CSS custom properties, and the components reference those variables rather than fixed colours. On top of the colour theme sits a "shade" setting that adapts the same palette to light, tinted, cream or dark backgrounds.
The payoff is significant: one set of components covers every colourway, the design stays coherent because the colours come from a single source of truth, and adding a new village identity later is a matter of defining a new theme, not rebuilding components.
Find your place to belong
Every block reads the same handful of tokens, so one dropdown shifts a page's entire mood while the layout stays put.
One component, every colourway and shade. Pick a colour and a shade above, the same markup recolours from a single set of CSS custom properties.
Four colours, four shades
On top of the colour sits a shade that adapts the same palette to light, tinted, cream or dark-navy backgrounds. The surface and accent recolour while the CTA stays prominent.
Migrating a decade of content out of Drupal
The single largest piece of work was getting years of content out of the old Drupal 9 site and into Statamic cleanly. I built a two-stage migration pipeline, both stages fully idempotent and safe to re-run.
Stage one is a Node script that crawls the live Drupal JSON:API, expands every referenced media item and file, normalises each record into clean JSON and downloads the associated assets.
Stage two is a Laravel Artisan command that reads that export and creates Statamic entries, converting Drupal's rich-text bodies into Statamic's editor format, copying images into the asset library and stamping every entry with its original Drupal ID so that re-runs detect and skip, or deliberately overwrite, anything already imported.
The villages themselves were handled differently. Each village page needs editorial judgement, which images are real photography versus marketing graphics, how the opening hours should read, which marketing copy to keep, so rather than a blunt import, the pipeline produces a curation packet per village and that final mile is done with a human in the loop.


Making a flat-file site fast
Statamic stores content as files and augments it richly on render. That is wonderful for editing and version control, but it makes it very easy to accidentally trigger hundreds of repeated lookups on a single page: every property in a list re-resolving its village, every card re-fetching its image. On a property catalogue or a village page, that adds up to hundreds of milliseconds and can exhaust memory. I addressed this on two fronts.
Resolve once, up front
Any component that renders a list of entries is backed by a custom tag that queries the data once, resolves everything (pricing, images, related villages) in PHP up front, caches shared lookups for the duration of the request, and hands the template plain, pre-resolved data. Fourteen of these custom tags power the heaviest parts of the site.
Serve static HTML
The site generates static pages. A build step renders every page to HTML up front, so visitors are served files rather than booting the full application on every request, and the front end stays extremely fast even under heavy load.
Integrations
-
Sherpa (sales tool)Every enquiry form submits leads straight into the sales team's CRM through a custom connector, routed to the correct village.
-
PageUp (careers)Live job vacancies are pulled from an XML feed, classified into village and central roles, and cached.
-
Interactive village mapA MapLibre GL map with all villages plotted, geocoded via OpenStreetMap's Nominatim service.
-
Consent & analyticsCookiebot consent management and GA4.
-
Eight enquiry formsBrochure requests, callbacks, village visits, home visits, event bookings and general enquiries, each validated and wired to the right destination.



Engineered to be simple to run
A deliberately lean setup with a fair amount of engineering underneath. The whole site is compiled to pre-rendered HTML by a build step, so visitors are never waiting on the application to boot. Content edits are committed straight to Git, giving a full, reviewable history of every change, and deploys follow a single, repeatable path. Easy for the client's team to live with, and quietly doing a lot of work to stay that way.
Static page generation
The whole site compiles to pre-rendered HTML ahead of time, so pages render instantly.
Git-tracked content
Every edit is committed to Git automatically, with a full version history of the content.
Automated, repeatable deploys
Server provisioning and releases run through a single, scripted pipeline, so shipping changes is routine rather than risky.
No per-request boot
Visitors are served files, not a freshly booted application, which keeps the front end fast under load.
A modern platform, delivered to a fixed go-live
Fast for real users, not just in a lab
Google CrUX field data · mobile · 75th percentile · 28 days to 30 May 2026and improving
and improving
but improving
This is real-world performance reported by Google from actual Chrome visitors, not a one-off lab test. Because it aggregates a rolling 28-day window, it takes a few weeks to catch up with the live site, so the post-launch gains are still feeding through. Loading and visual stability already sit comfortably inside Google's "good" band, interactivity is a hair over the threshold and climbing, and post-launch work is ongoing to push it the rest of the way. Explore the live data.
Responsive, by an audience that expects it to just work



Tech Stack
Noteworthy technologies, tools and frameworks behind the build:
- Statamic 6 (Pro)
- Laravel 13
- PHP 8.5
- Tailwind CSS 4
- Alpine.js
- MapLibre GL
- Vite
- Laravel Forge
- Static page generation
- Git-tracked content
Development, CMS and integrations by Steve Edson. Designed by Jane Richardson and delivered with Apogee Creative.
It's been a huge project and I don't think anyone else out there would have put the thought, time and effort in that you have. Really appreciated. Great to work with and a great team around you.
Andrew Regan
Head of Marketing, Inspired Villages
Have a content-heavy site that needs to stay fast?
That mix of editor freedom, clean migration and real performance is exactly the kind of build I enjoy.