Reusable CMS framework that cut new project deployment time by 40%

The situation

A digital agency was starting each new client project by rebuilding the same CMS foundation from scratch. Content type configuration, role-based access, media management, SEO fields, and deployment pipelines were being set up identically on every project — consuming 3–4 weeks of a developer's time before any client-specific work could begin. When a bug was found in the common authentication layer, it had to be fixed separately in every active project.

There was no shared component library, no deployment template, and no documentation that a new developer could onboard to in under a day. Knowledge lived with individuals. When someone left, the next project that touched their code required reverse-engineering before anything could be changed.

The agency had considered simply standardising on a popular off-the-shelf CMS, but their client base spanned real estate, e-commerce, and professional services — industries with different content models that a single generic tool couldn't serve well without extensive per-project customisation anyway. What they actually needed was a shared foundation flexible enough to specialise quickly, not a one-size-fits-all product.

What we built

Pluggable content type system

A Strapi-based core with a plugin architecture for content types. Common types (pages, blog posts, team members, testimonials, FAQs, media) are included in the core. Industry-specific types (products for e-commerce, listings for real estate, courses for education) are registered as plugins. Starting a new project means enabling the relevant plugins — not writing new schemas — and a plugin built for one client's real estate site can be reused, largely unmodified, on the next real estate client.

Role and permission templates

A library of pre-configured permission sets for common client structures: single editor, multi-editor with approval workflow, agency-plus-client with restricted access, and full admin. Applied at project initialisation. Customised per client as needed, but the starting point is always a working, secure configuration — not blank permissions.

Deployment templates

A set of Terraform and GitHub Actions templates for common hosting configurations: Cloudflare Pages (static sites), Vercel (Next.js dynamic), and Docker Compose (self-hosted). New project infrastructure deploys in under 20 minutes from the template, compared to a developer previously hand-configuring hosting, DNS, and CI from scratch on every new engagement.

Theme engine

A CSS custom property-based theming system where brand colours, typography, and spacing are defined in a single config file. The framework renders correctly with any theme config — no per-client style overrides scattered across component files.

Documentation as part of the deliverable

The framework ships with living documentation covering plugin authoring, permission templates, deployment steps, and theming — written for a developer who has never touched the codebase before. This was treated as a first-class deliverable, not an afterthought, because the framework's value depends entirely on whether a new team member can actually use it without hunting down whoever built it originally.

Results

• ~40% reduction in new project deployment time
• ~50% reduction in development reuse overhead — common functionality is written once
• ~35% improvement in maintenance efficiency — bug fixes in core propagate to all projects
• New developer onboarding reduced from 2 weeks to 3 days with framework documentation
• Cross-project consistency — security, SEO, and accessibility baseline is the same everywhere

Where this fits

This framework grew out of our web development practice and now underpins the deployment approach behind several of our custom software engagements. The Terraform and container templates draw on the same discipline as our cloud & DevOps work — if you're running multiple client sites or products off inconsistent foundations, that overlap is usually where the savings are.