One Frontend Foundation Powered 3 Product Surfaces of a US Public Health Data Platform

Industry

Healthcare & Life Sciences

Geography

United States (Midwest)

Cooperation Period

8 phase engagement

About the Client

The Client is a US public health data analytics company that operates a national data platform trusted by state and local health departments, foundations, community coalitions, and academic researchers as the backbone for community health decision making. The platform aggregates federal indicator data from the American Community Survey, CDC PLACES, the USDA Food Access Research Atlas, and dozens of other public sources, then publishes them at county and Census tract resolution across every US community.

The output sits behind decisions that carry population health consequences. Community Health Needs Assessments that nonprofit hospitals file on a regulatory cadence. Grantmaking priorities set by foundations working on health equity. Resource allocation choices made by health departments serving hundreds of thousands of residents. The data has to be trusted, timely, comparable across geographies, and legible to a public health analyst who does not carry a data science background.

The Client engaged Clixlogix as an external engineering partner after evaluating multiple firms for a long term partnership. 3 of the platform’s core user surfaces came from this engagement. The Project Board Cards platform where users compose indicator dashboards, the Map Room geographic explorer where they navigate the same data at county resolution, and the Publisher story surface where they turn their analysis into published content. All 3 remain in production on The Client’s live platform.

Challenge

The Client had a technical cofounder carrying GraphQL schema design, API infrastructure, and the frontend build at the same time, and a public launch commitment aligned to an annual public health data release cycle. A prior contractor had produced a React prototype with draggable report cards, but the prototype had no API integration, no geographic module, and no path from local development to production release. 5 constraints defined the engagement scope.

A frontend build that had to ship the same platform 3 different ways. The launch platform needed a Project Board where users composed indicator dashboards from draggable cards, a Map Room where users explored the same indicators geographically at county, ZIP, and state resolution, and a Publisher flow where users turned their boards into full page stories that lived on WordPress with the platform’s CMS. 3 product surfaces, all reading from the same GraphQL API, all writing back into the same shared save contract. Building each surface as an isolated codebase would have multiplied engineering cost and produced 3 different user experiences the same team then had to maintain.

A stack that shut out most React contractors. The frontend was written against a GraphQL API compiled by Relay, which meant any engineer joining the project had to be comfortable with Relay’s compile time query system, fragment composition, and the runtime store. Most React contractors bidding for the work knew React, and stopped at React. The Client needed a team that could read the schema, extend the Relay query graph, and ship against it in the first week.

A launch date tied to a public health data cycle. The Client had committed to a launch date aligned with an annual public health data release cycle, publisher partnerships, and downstream research users who plan their work around the platform’s data drops. Slipping the launch would have set the platform back a full annual data cycle.

A geographic module that had to interoperate with the rest of the platform. The Map Room needed to render US health data at county, ZIP code tabulation area, and state resolution, overlay indicators with independent transparency, retrieve indicator and shape data from the API bounded to the current map viewport, and save each map view as a card that landed back in the Project Board through the same save contract every other card type used. Treating the Map Room as an isolated map product would have broken the platform’s unified card container thesis.

A rich text editor and publisher surface with real CMS integration. The Publisher flow turned a project board into a full page story rendered on WordPress with a Wagtail CMS backend. That required a Slate.js rich text editor inside the platform for section descriptions, a serialization contract from Slate to Wagtail on save, and a story card publishing flow that stayed inside the same login and permission model as the rest of the platform. This required a dedicated R&D discovery investment before a single production feature shipped.

Approach

Clixlogix structured the engagement around a single architectural premise the team carried across every product surface. The shared frontend foundation treats every user artifact on the platform as a card. When a user saves a data view, a map exploration, or a published story, all 3 land in the same place on their Project Board, all 3 can be embedded on any external website through the same short URL, and all 3 speak to the platform through the same underlying application interface. The Project Board is the container. Every other surface is a card producer. Building this contract once meant every product surface Clixlogix shipped later inherited the same save, share, and reuse behaviour without engineering it again from scratch.

Fig 1 – Shared Frontend Foundation Across 3 Product Surfaces

The card contract sits below all 3 producer surfaces. Building it once meant the Project Board editor, the Map Room, and the Publisher flow all inherited the same save behaviour, the same embed URL stability, and the same query API. Each producer’s specific consumer experience stayed isolated above the shared contract.

Phase locked delivery carried the second architectural choice. Clixlogix ran the engagement as 8 named phases, each with hour estimates set at the phase open, actual hours logged daily against a shared board, and closure at or under the estimate before the next phase opened. The Client’s technical cofounder and the Clixlogix team worked from the same live tracking sheet. Variance surfaced inside the phase where it originated and got resolved before the next phase opened.

Consulting Insight

On a small startup account, the frontend vendor's first job is to identify the one architectural decision that will make every subsequent product surface cheaper to build, before a line of React gets written. On this engagement, that decision was the shared frontend foundation. Every product surface Clixlogix shipped fell out of that single choice, which is why the fourth product surface, which came years later, shipped without Clixlogix in the loop.

Solution

Clixlogix structured delivery across 4 workstreams running against the engagement window, each completing a production user journey end to end.

Fig 2 – Production Architecture Across 4 Workstreams

Shared Frontend Foundation

The team engineered the card contract first as the foundation all 3 producer surfaces would depend on. The React frontend consumed a Relay compiled GraphQL client that shared queries, fragments, and mutations across every producer. Clixlogix built the auth surface, including the “Before you can do that” login gate that intercepted card creation attempts by unauthenticated users, once and shared it across every producer. Clixlogix built the Save Card dialog once with the destination boards and sections list retrieved from the API, and every producer surface reused it.

The foundation carried the query cost discipline. Every fragment was designed to fetch what the local component needed and nothing more. Where a container component fed multiple children, a single shared fragment on the container carried the payload for the whole subtree. The Client’s technical cofounder set the ceiling on API cost per view. Clixlogix’s engineering lead paired with the cofounder on fragment composition and defended the ceiling across the entire engagement.

Consulting Insight

When a small startup's technical cofounder is carrying schema, API, and frontend at the same time, the frontend vendor's most valuable contribution is protecting the cofounder's attention. Every hour Clixlogix spent on Relay fragment composition was an hour the cofounder did not have to spend explaining query cost implications to a vendor who would have overfetched otherwise.

In use, this foundation meant every product surface Clixlogix added later inherited the same login, save, and reload behaviour without engineering it again. A user who signed in once could favorite a data card, save a map card, and publish a story card, all through the same actions on the screen. For The Client, the shared foundation was the reason each new product surface after the first cost less to build and delivered more to the user.

Project Board Cards Platform

The Project Board came up first on top of the shared foundation. The build ran across 6 named phases over the front half of the engagement, tracking against a daily hours ledger the team ran with the client.

The Project Board workstream shipped as a coherent authoring environment for the platform’s users. Users could search and filter the platform’s content from a homepage, mark items to Favorites with persistent state, group related items into Collections with drag and drop layouts, edit section descriptions with a rich text editor, publish Collections as story cards, and manage collaborators with invite flows and cropped profile pictures. Every one of those surfaces shared the same GraphQL client, the same auth state, and the same card contract underneath. The engineering coherence was invisible to users, which is what let the platform grow later without a team of engineers to maintain it.

Clixlogix engineered the drag and drop layout persistence against a Slate.js serialization schema that the API could consume without translation. When a user rearranged cards inside a section and hit save, the resulting layout landed in the same createCard shape every other producer used. The Project Board did not need a special case for its own outputs.

Phase discipline held visibly across the workstream. The Client’s technical cofounder could see, on any given day, which task was ahead or behind, which had unresolved dependencies, and which had moved to the next phase. Delivery variance surfaced and got resolved inside the phase where it originated. No status meetings.

For a user of the platform, this workstream is the home base. It is where they browse Featured Indicators, save what they care about to Favorites, group related items into Collections they can revisit and share, and publish those Collections as public stories for their team or the wider community. For The Client, the daily hours ledger meant the technical cofounder always had a live view of what had been done, what was in progress, and where the money was going. There was no vendor spin to filter out.

Fig 3 – Project Board Cards Producer Surface

Map Room Geographic Explorer

The Map Room came up as the second producer surface in parallel with the later Project Board phases, running across 2 named phases and closing ahead of the launch date. It was Clixlogix’s proving ground for the shared foundation premise. Could a distinct product surface, with its own data model and its own user experience, save into the same Project Board container as a native card?

The Map Room platform accepted an area search, rendered US health indicator data on a Mapbox base map at county, ZIP code tabulation area, or state resolution, and supported multi overlay indicator views with independent transparency controls. Users added indicators from a searchable indicator library, saw each indicator become a distinct overlay with its own visibility and alpha, adjusted geographic unit per overlay through an API call that mapped indicators to the closest available data set, and captured the map as a Map Card that landed in the Project Board through the shared card contract.

The save flow was the architectural test the shared foundation premise had to pass. When a user pressed Save on the Map Room, the platform captured a thumbnail image of the current map view, wrote a createMapCard mutation carrying the overlay set, center, zoom, area selection, and thumbnail into the shared card contract, and returned an id. The Project Board pulled the resulting card in through its embed URL scheme with that id. From the user’s perspective, a Map Card looked identical to any other card on the board.

Fig 4 – Map Room to Project Board Save Contract

QA sat on The Client’s side. The Client’s technical cofounder ran a strict pull request review discipline that required continuous test coverage on every merge and a minimum code coverage score before a PR would move forward. Every Clixlogix PR carried tests written alongside the feature, met the coverage threshold, and passed cofounder review before landing in main. Review concerns surfaced as line comments on the PR and resolved inside the same review cycle.

The Client ran 2 formal QA passes on the Map Room ahead of production. The first pass covered the happy path across the search, indicator selection, save, and export flows. The second pass surfaced a long tail of edge cases around overlay independence, transparency slider mapping to overlay ids, and the handleMapLayerRemoved function firing more than once per overlay removal. Each issue got a named entry in the shared tracking sheet, an estimate, and a close date. The Clixlogix team wrote regression tests against every fix so the same class of bug would surface in the coverage report on any future PR before it could regress to production.

Consulting Insight

A client running continuous testing gates on the vendor's pull requests is the strongest engineering discipline a small startup can impose on an outside team. Every PR becomes a documented contract about what the feature is supposed to do, and the coverage report enforces that contract on any future engineer who touches the code. The engagement handoff carried a test suite The Client's team could keep extending without a Clixlogix engineer in the loop.

For a user, the Map Room turns the platform’s indicator library into a US map they can explore county by county. They add the indicators they care about, adjust how prominent each overlay is on the map, change the geographic resolution between county, ZIP code area, and state, and save the resulting map back to their Project Board with 1 click. The saved map behaves exactly like any other card on their board. For The Client, the save contract discipline meant the Map Room shipped as a first class product surface on day 1, not a bolt on that the platform’s regular Project Board features would have to work around.

Publisher Story Surface and Post Launch Iteration Round

The Publisher workstream extended the Publish flow from the Project Board into a full page story rendered on WordPress with a Wagtail CMS backend. When a user pressed Publish, the platform serialized the project board’s Slate.js content, called the API integration Clixlogix built into WordPress, and produced a full page story that lived at a WordPress URL. The Story Card returned to the Project Board through the same shared card contract as every other card type.

Following launch, the engagement continued through a post launch iteration round that ran for roughly a quarter. The round consolidated the platform’s group collaboration surface across the My Collections feature set, tightened the mobile and tablet experience, and shipped the profile picture editing flow behind the react avatar cropper. Enhancements to the Publish popup, the section description editor, and card refresh behaviour on favorite add and remove tightened the interactive feel of the platform without changing its shape.

The round ran under the same phase discipline as the launch phases. Every issue carried an estimate, a design spec link on Adobe XD, and a close date.

For a user, the Publisher flow turned a working Project Board into a full length published story on The Client’s public website, which is how the platform’s most valuable content reaches audiences beyond registered users. The post launch iteration round refined the rough edges that only surface under real user load and shipped a batch of My Collections upgrades that made group content easier to organize and share. For The Client, the ongoing iteration confirmed the vendor relationship as a durable partnership, useful for the platform work still ahead.

Results

The 3 product surfaces launched on schedule and remain live on The Client’s platform. For The Client, the engagement delivered 4 material business outcomes.

3 Product Surfaces Shipped Into a Live Community Health Platform

The Project Board Cards platform, the Map Room geographic explorer, and the Publisher story surface all shipped under The Client's brand on the launched public platform. All 3 surfaces write into a shared card container through the same save contract, and all 3 remain active in production.

Shared Frontend Foundation Reused Across Every Producer Surface

A single Relay compiled GraphQL client, a single auth surface, a single Save Card dialog, and a single embed URL scheme served all 3 producer surfaces. Each new producer surface Clixlogix added inherited the foundation without rebuilding it. The Client's technical cofounder set query cost ceilings on the shared fragments once and every producer surface stayed under them by construction.

8 Phase Engagement Delivered Under Budget Where Measured

The engagement ran 6 phases on the Project Board workstream, 2 on the Map Room workstream, and a post launch iteration round under the same delivery discipline. Every measured phase closed at or under the estimate set at the phase open. Variance surfaced inside the phase where it originated and got resolved before the launch date.

Platform Launched On Schedule and Continues in Production Under Client Engineering Ownership

The platform launched on the target date and remains in operation at its public URL. Years after launch, The Client's own engineering team has continued to extend the same shared frontend foundation without Clixlogix engineering in the loop. The engineering choices Clixlogix made during the original build, particularly the Card Contract and Relay fragment discipline, held up under technical audits.

Technologies and Tools

Layer	Stack
Frontend	React for all 3 producer surfaces, react grid layout for drag and drop card composition, Slate.js for rich text section descriptions and story serialization, react avatar cropper for profile pictures, Mapbox for the geographic base map and indicator overlay rendering
API	GraphQL with the Relay compiler for compile time query composition, fragment first component data contracts, shared mutations for the card contract including createMapCard and Story Card creation
Content and Publisher	WordPress as the public story surface, Wagtail CMS backend for story publishing, custom API integration between the platform Slate.js content and the WordPress publisher
Design and Specification	Adobe XD for design specification, with per screen and per component prototype links referenced against each engineering task
Quality Assurance	Client owned QA with a pull request review discipline requiring continuous test coverage and a minimum code coverage score, regression tests written against every bug fix, GitLab issues for tracking
Delivery	Trello for daily task tracking with per task estimated and logged hours, GitLab for code and issue tracking across separate project board and map room repositories, Dropbox for design documentation, weekly Zoom syncs

Services Delivered

Digital Engineering, Web Development, AI and Data Analytics, Quality Assurance & Testing, Consulting Service

Team Composition

Technical Architect, Frontend Engineers, Backend Engineers, QA Engineers, UI and UX Designer, Project Manager

Have a question for our team or need help with your project?

Our team can share client references, scope your project, and answer any question about your delivery.

Related Case Studies

More engagements where our delivery teams shipped similar outcomes for clients across industries. Read on for context on the patterns we reused, the trade offs we navigated, and the metrics that landed in production.