Sustaining Data-Rich Web Portals with Limited RSE Resources: A Headless CMS Pattern

Public-facing sites for scientific and policy reporting constantly evolve as narratives, imagery, and visualizations are revised by domain experts with little to no coding experience. While edits are continuous and unpredictable, developer capacity remains limited. This leads to a bottleneck that delays updating cycles.   It reflects not a shortage of development time, but where the boundary between content and code is drawn.

Existing approaches draw this boundary in different places, each striking a different balance of editorial reach and engineering effort. Code-first and static site generator (SSG) approaches are flexible but require code changes and redeployments for routine content edits. Traditional content management systems (CMS) make content editing easy for non-coders but struggle to support reusable, interactive components like dynamic charts. Visual Analytics tools excel at open-ended data exploration but are less suited to narrative, page-level storytelling. None of these options let a non-coder restructure a narrative page containing live, styled, accessible visualizations.

We address this gap with a headless CMS architecture, a system that separates content storage from the frontend. Content is structured as data and served through application programming interfaces (APIs) to a developer-built frontend. This split lets developers focus on dynamic components while domain experts control the content and data. We demonstrate this pattern on the public portal of the Illinois Nutrient Loss Reduction Strategy (NLRS), which is the Illinois statewide initiative to reduce nitrogen and phosphorus pollution in Illinois waters. We chose Strapi, a self-hostable, open-source CMS, over alternatives like WordPress and Payload because it pairs composable-block content modeling with an admin interface simple enough for non-technical contributors. 

Strapi is paired with a component-based frontend built in Next.js. Pages are modeled as an ordered sequence of blocks where each block type maps to a specific frontend component. Chart data and display configurations are stored as structured data (JSON) allowing per-chart customizations in the CMS. The site currently utilizes 25 reusable components to create 60 pages having more than 90 data visualizations. Per-chart-type Python scripts update this full chart set through Strapi's API each year, in a matter of minutes. Some data, particularly exploration-heavy geospatial views, is better served by embedded dashboards than by native components; we currently use the commercial tool, Tableau.

This division of labor extends to accessibility. Component-level concerns, such as color contrast, are tackled by the developer in the component library. Content-level concerns, such as screen-reader descriptions, are authored by domain experts within the CMS. The result is that site-wide accessibility becomes easier to achieve and maintain.

Development is concentrated in the beginning and then tapers off, making  handovers to non-coders easy. 56% of components existed within 5 months of the project. This is reflected in the commit history: half of all commits landed within a 2-month window. The CMS's intuitive interface meant only brief training and documentation were needed, and a staged dev-to-production workflow let contributors edit without risking the live site. Narrative content no longer requires developer involvement; only chart and data updates still route through the developer, which requires only rerunning a few scripts.

The architecture has real costs: consistent component mapping requires ongoing design discipline as the site grows, and the addition of a CMS introduces one more point of failure. However, by drawing the boundary between content and code clearly, we are able to sustain a public, data-rich site with just one developer while domain experts retain complete ownership of structure and content — a pattern that can be adopted by other small teams facing the same asymmetry.