Visual CMS editor skin for content teams

A content editor sits down to update a page in their company's CMS and immediately needs help from a developer just to find the toolbar. That's the moment. It happens every time someone new joins the team, or every time a non-technical stakeholder needs to make a quick update. Nobody's fixed this properly because the CMS vendors have no real incentive to: their buyers are IT directors and developers who evaluate on architecture, integrations, and compliance — not on whether a content coordinator can figure out where the editor bar is. The UX complaints come from users, not buyers, so they sit at the bottom of the backlog indefinitely.

What the complaints describe is specific and structural: widget toolbars hidden in layers of UI requiring extra CSS to even see, WYSIWYG output that generates messy markup editors can't clean themselves, and table elements that aren't responsive so mobile layouts break after every edit. These aren't bugs — they're the result of interfaces built by and for developers, never redesigned for the people who use them eight hours a day.

A standalone editor layer that mounts on top of existing CMS APIs and replaces the editing UI — without touching the underlying content model or infrastructure — lets organisations keep their CMS investment while giving content teams an interface designed around their actual workflow. The need recurs every time a new editor joins, every time a campaign requires fast page updates, and every time a broken table on mobile costs someone an afternoon chasing a developer.

What to build

Build a browser-based editing interface that connects to headless CMS APIs (starting with Agility CMS and ApostropheCMS REST endpoints) and replaces their default admin UI with a clean, responsive editor — including a structured table builder that outputs semantic, mobile-safe HTML and a WYSIWYG that enforces clean markup via configurable output rules.

Where to start

Start with companies already on ApostropheCMS who have a developer on staff but a non-technical content team — the developer can handle the API integration, and the content team is the one suffering daily, making internal buy-in structurally easy.

The hard part

CMS APIs vary enough across vendors that a clean abstraction layer that handles structured content, rich text, and widget configuration without breaking edge cases for any of them will take longer to build than the UI itself — your first customer will expose gaps you didn't anticipate.

How it makes money

Monthly subscription per content editor seat, with a one-time setup fee for the initial CMS integration.