Compose
Build varied pages from approved sections, columns and content blocks.
Case study
SimpleCog · CMS & application platform
Eighteen years of turning complex digital products into simple editing experiences.
I designed and evolved SimpleCog, a modular CMS and application platform that powered more than 100 commercial websites, campaigns, SaaS products and operational systems.
- Role
- Product architecture, UX and full-stack engineering
- Scope
- CMS, page building, workflows, media, SEO and bespoke applications
- Timeframe
- 18 years of continuous evolution
01 · Overview
A small editing tool that grew into Webfire’s technical foundation.
SimpleCog began before my time at Webfire as a basic way to change selected lines of website copy. Over the following 18 years, I designed and built the platform it became: a modular CMS and application framework used across more than 100 commercial projects.
The earliest iterations involved collaboration, but I became solely responsible for the modern product, including its architecture, interface and core engineering. It evolved from authenticated text editing into a foundation for content-managed websites, campaigns, subscription services, booking systems, employee communities and complex operational tools.
The platform’s defining principle remained consistent throughout: give each organisation the capabilities it genuinely needed while keeping the experience simple for the people responsible for its content.
100+commercial projects powered
85%of Webfire’s digital delivery
17 yearsfor the longest-running installation
02 · The challenge
More capable than a generic CMS, without feeling more complicated.
Clients wanted control of their content, but many arrived frustrated by repeated security problems, plugin dependencies or administration systems that were difficult for non-technical teams to learn.
A completely bespoke CMS for every project would repeat the same engineering and make long-term maintenance expensive. A fixed, all-purpose interface would expose settings and concepts that most editors would never need.
SimpleCog had to sit between those extremes: a dependable shared foundation with enough modularity to power very different products, presented through an interface tailored tightly around each client’s real responsibilities.
Complexity belonged in the platform—not in the editor’s day.
The principle behind each implementation
03 · Product evolution
Each generation responded to a problem already visible in live client work.
SimpleCog did not begin with an eighteen-year roadmap. Its capabilities developed through repeated observation of what editors, designers, developers and operational teams actually needed.
- 01
From copy changes to content management
Authenticated editing expanded into TinyMCE rich text, file uploads, complete page creation and a drag-and-drop page tree. Upload progress initially relied on Flash before being replaced by modern JavaScript alternatives as the browser platform matured.
- 02
From pages to reusable modules
CMS capabilities became modular functions that could be selected and configured for each project. Shared foundations covered content, files, users and navigation while custom fields and project modules extended the system without changing its underlying data model.
- 03
From fixed templates to structured composition
Templated rows introduced reusable content blocks for text, images, video, embeds, maps and accordions. These evolved into responsive sections, columns and stackable blocks with controlled spacing, layout and animation options.
- 04
From publishing to governance
Role-based access, approvals, versioning, scheduled publishing, reusable sections, multilingual content, audit history, one-time-code MFA and richer media management supported larger editorial teams and more accountable workflows.
- 05
From CMS to product platform
Forms, integrations, search, first-party analytics, image processing, prerender caching and bespoke application modules allowed the same foundation to support products far beyond conventional marketing websites.
04 · Editor experience
Powerful where it mattered, deliberately absent where it did not.
Every implementation exposed only the content types, blocks, fields and controls appropriate to that product. Editors were not asked to navigate a marketplace of features or understand the underlying technical model.
Templates and block availability acted as design guardrails. They gave teams meaningful control of layout while protecting brand consistency, responsive behaviour and the semantic structure of the public page. The editor inherited front-end styles, and a full rendered preview showed exactly how the finished page would behave.
Even complex installations generally required no more than an hour of client training. After more than 15 years working with content across many CMSs, PlasticFree’s Head of Content described SimpleCog as the most pleasant and intuitive system she had used for creating content and reviewing contributors’ work.
05 · Structured flexibility
A page builder designed around reusable decisions, not an empty canvas.
The drag-and-drop builder arrived several years before block-based editing became a common expectation. Its purpose was not unrestricted visual design; it was to make approved design patterns reusable by content teams.
Editors could compose pages from project-specific sections, responsive columns and stackable blocks. Available blocks included rich text, responsive images, video, YouTube and Vimeo, maps, embeds, accordions, forms, dividers and purpose-designed campaign or product components.
Rows and columns carried controlled options for spacing, alignment, responsive stacking and reveal behaviour. Reusable sections and templates allowed repeated content to retain a single source of truth while still supporting local variation where a page required it.
Constrain
Expose only the options that made sense for the product and its design system.
Reuse
Share templates and canonical content without duplicating future maintenance.
Preview
Review the fully rendered page before publishing or scheduling a change.
06 · Under the surface
A stable core, extended around the product it needed to power.
Modular architecture
The PHP, MySQL and JavaScript platform used folder-based modules around a consistent core data model. Project-specific fields and functionality could be added without making every client inherit the same interface or feature set. A basic brochure website—including a completely bespoke visual theme—could be assembled in a matter of days, while the same foundation could be extended into much larger applications.
Performance-aware media
Images could be uploaded at full resolution, assigned a focal point and processed only when a particular output was required. The platform generated correctly sized responsive assets in modern formats and cached the result. In one representative conversion, an 18MB source JPEG became a sub-100KB WebP with minimal visible loss at its delivered resolution.
Search, discovery and measurement
SEO support evolved with the wider web: automatic XML sitemaps, redirects, canonical controls, social metadata, structured data and editable search previews were built in rather than added through paid plugins. First-party analytics could record page activity, events, downloads, searches and success rates, reading time and scroll depth while reducing reliance on third-party tracking.
Forms and integrations
The form builder supported standard field types, validation, required and optional fields, tailored success and failure states, spam protection and controlled uploads. Submissions could be emailed, stored for managed export or routed into bespoke and third-party actions.
07 · Range and scale
One foundation serving campaigns, global organisations and high-traffic platforms.
SimpleCog powered around 85% of Webfire’s digital delivery, from single-page campaigns to long-running platforms for organisations including Excel London, McDonald’s, PlasticFree, Airbus, Saab Seaeye, BNP Paribas, Close Brothers, Cognizant and Computacenter.
The demands varied substantially. Excel averaged around 40,000 page views per day and accumulated more than 136,000 content updates. A London property platform supported the broadest multilingual implementation, including multiple Chinese-language variants. PlasticFree required five levels of editorial access, while McDonald’s and Excel each supported administrative teams numbering in the twenties.
Clients repeatedly returned with new projects because the core was already understood and the editing experience remained familiar. The oldest surviving installation has operated for 17 years, requiring only PHP compatibility work rather than migration to the latest generation of the platform.
40Kaverage daily page views at Excel
136K+content updates recorded at Excel
<1 hourtypical client CMS training
08 · Reflection
A successful product does not have to become a permanent answer.
For much of its life, SimpleCog offered a combination of flexibility and usability that clients struggled to find elsewhere. Today I would not begin by building the same platform again.
The market caught up. Site builders and AI-assisted tools changed the economics of simpler websites, while established enterprise platforms expanded their capabilities—albeit often with greater cost and less consideration for the day-to-day editor. Webfire’s liquidation also removed the commercial model that had sustained continued platform development.
There were engineering lessons too. Major PHP changes placed pressure on a long-lived custom core, and replacing jQuery-era dependencies with native JavaScript required sustained modernisation. Two major generations became substantial rewrites. Although modular code kept individual changes manageable, upgrades were not distributed automatically: retained clients received newer capabilities, while heavily bespoke or unmaintained installations remained on stable historical versions.
If rebuilding the surrounding process, I would prioritise automated migration and deployment earlier, treat accessibility within the administration interface as a first-class requirement and assess more aggressively where established services could replace owned infrastructure.
What I would carry forward is the central product lesson: powerful software feels simple when its architecture, constraints and interface are shaped around the people who actually use it.