A publishing system with two jobs
TechCrunch asked Human Made to redesign its site and streamline its CMS. The project account describes an editorial team that needed a modern publishing environment, alongside a reader experience built for technology news and storytelling. Human Made chose a headless architecture: WordPress managed content and React rendered the frontend on managed WordPress hosting. [1]
That division mattered because the CMS and the public site served different users. Editors needed a familiar place to publish; readers needed an evolving interface. The WordPress REST API provides a structured way for applications to access site content as JSON, which can support a separate frontend. That capability explains the architectural option, but does not itself establish a project result. [2]
Keep the editorial workflow steady
Human Made describes the frontend as separate from the CMS so the presentation could change without replacing the editorial tool. In practical terms, continuity can be a product requirement: if editors retain the same publishing environment during a redesign, training and handoff work may be more contained. That is an architectural rationale, not evidence that every editorial task became easier or that no workflow changes were needed. [1]
A proposed follow-up would map the full publishing path: draft, preview, review, publish, correction and withdrawal. For each step, document who owns it, which system displays its status, and how an editor knows the public page reflects the current version. A preview check should confirm that an editor can inspect the React-rendered story, including images and embeds, before release. This would turn “keep the tool” into a testable continuity commitment.
Make the homepage river legible
The documented homepage river let readers open an article within the homepage stream, follow a progress indicator, reach the end, and return to the river as the story closed. Human Made says the feature was intended to help readers move among articles without losing their place. [1]
This interaction couples reading and navigation: an expanded story occupies the stream, while closure returns a reader to a previous browsing context. A useful follow-up would define what happens when someone opens a story from a direct link, refreshes mid-article, uses browser back, or opens a second story. The acceptance criteria should specify the expected URL, history entry, scroll restoration and deep-link behavior for each path. These are proposed checks; the case account does not document their implementation.
Treat measurement as part of the experience
The project account identifies a specific challenge: articles could be reached through the homepage river or from an external source, while analytics and advertising required article-level view data. Human Made says accommodations were needed so data would be available across those entry paths. [1]
A follow-up acceptance checklist should verify that each article has a stable URL; browser history reflects open and close actions; a copied deep link opens the intended story; the page title identifies that story; analytics records a single article view consistently for homepage and external entry; and editor preview works before publication. Measurement rules should distinguish a new article view from repeated rendering during navigation, with the agreed behavior written down before implementation. This is proposed validation, not a claim about the historical tracking design.
Choose separation for a reason
A business CMS benefits from a separate presentation layer when the organization needs a distinct interactive experience, expects frequent frontend redesigns, or serves content to multiple applications. WordPress’s REST API can supply structured content access for a separate application. [2] But separation also creates a continuing integration boundary: teams must maintain the connection, preview path and compatible content model. If a conventional WordPress theme already meets editorial and reader needs, adding a separate frontend may create maintenance without a clear business benefit; WordPress documentation itself says the REST API is optional. [2]
For a similar publisher, the proposed next step is a decision record with editorial requirements, reader journeys, measurement needs, ownership and ongoing support capacity. Approve separation only when those needs justify operating both sides of the boundary, then carry the checklist above into release review.
Sources & useful references
Results are attributed to the original publisher. Proposed tests and creative recommendations are our analysis.
