We Chose Prismic. Here’s What We Still Had to Build.

In a Prismic project, content management is one part of the backend design. Search may need its own update pipeline, page sections may depend on external datasets, and a connected application may require shared authentication. Each responsibility introduces an integration you need to understand before choosing how the site runs.

Our Prismic project overview links to implementations with different combinations of these requirements. Taken together, they offer a useful way to plan the infrastructure: identify who edits information, which system supplies it, and what must happen when it changes.

Separate content management from application delivery

A headless content management system (CMS) separates the editing environment from the application that presents the content. That gives the application room to use its own framework and hosting, while editors work through a content model built for their needs.

For Checkly, we built the marketing website with Next.js and React, deployed it on Vercel, and used Prismic for content management. We defined the content structure, templates, and fields with Checkly's team so routine publishing could happen without a developer.

The editing experience depended on that modeling work. Choosing the CMS established the platform; defining what editors could create made it useful in daily operations.

The AI Alliance implementation used Next.js, Prismic, and Vercel too. We built a library of custom components with Slice Machine, Prismic's component development tool, so the team could compose page layouts. Vercel provided the website's hosting.

For an infrastructure plan, record these as separate responsibilities: managing structured content, implementing its presentation, and hosting the application. A component library explains how editors assemble pages. A hosting choice explains where the website runs. You still need to specify any connections between publishing and application delivery that your project requires.

Give search an explicit update path

Canvas Medical provides a concrete example of the backend work surrounding a CMS. Its resource platform used Prismic for content and Algolia for search and filtering.

We connected them through a webhook, an event notification sent to another service. A change in Prismic triggered the webhook, which activated a serverless function. The function fetched the updated data, prepared it, and synchronized it with Algolia.

That sequence identifies where the integration work happens. The notification starts the process; the function retrieves and prepares the information that the search service needs. Publishing content and updating searchable data are distinct operations connected by this flow.

If your application also uses a separate search service, document that path explicitly. Name the event that starts synchronization, the code that prepares the content, and the destination it updates. Canvas Medical's account documents this sequence without specifying retry behavior or measured synchronization latency. Those details need their own design decisions before you can make reliability or timing commitments.

Keep external datasets connected to their source

Pathpoint needed to reduce the work of manually synchronizing information across its website. We built controls in Prismic that let editors select a dataset from a dropdown and use external data to populate a page section. When that data changed elsewhere, the website synchronized with it. The Pathpoint case study describes this alongside its Slice Machine editing experience.

The useful architectural distinction is between choosing content for a section and maintaining the underlying dataset. An editor can make the placement decision in Prismic while the values come from another system.

For a similar integration, start by identifying which information belongs in editable fields and which should come from an existing source. That decision determines whether a routine update means editing a document or retrieving changed data.

Pathpoint's account does not identify the upstream systems or synchronization mechanism. The transferable pattern is the editor's dataset selection and the automatic population of a section. Choosing a polling interval, webhook, or other update mechanism requires more information about your own source system.

Plan shared authentication across applications

GoHealth's requirements expanded after its website launched: a new patient portal needed to share authentication with the existing site. We used Next.js with NextAuth to connect authentication across the website and portal, and integrated website functionality with data from the portal.

We also converted the website into a Turborepo monorepo, a repository containing related projects, to reduce configuration complexity. The website and portal could share configuration and components. GoHealth's application programming interfaces (APIs) supported operations including profile updates, test results, and appointment booking. These responsibilities are documented in the GoHealth case study.

Shared authentication and shared code addressed different needs: a connected patient experience and less duplicated project setup. Neither detail specifies the session implementation or where patient data is stored.

When planning a comparable portal, identify the applications that must recognize the same user and the APIs that supply each operation. Then assess which configuration and components they should share. That gives you concrete requirements for the authentication integration and repository structure before implementation begins.