Building Bold's content and publishing platform

As Bold continued to grow at a rapid pace, our content and publishing platforms weren't getting the attention they needed and were starting to weigh us down.

With all the content directly in the code, we didn't have a way for our content team to directly interact with our content, so everything required developer intervention. Very little had been reused as components and pains like one-offs and inline styles made orchestrating changes across the site cumbersome. To make matters worse, our in-house spun up Google Cloud Platform hosting gave us nearly hour long builds and only a single staging account for all the various marketing initiatives we had brewing at any one time.

Having a background in agency work that involved building and migrating all kinds of sites, this project was one I was familiar with. I began setting up some my current toolset, Next.js for handling the frontend and Sanity for handling the storage and retrieval of our content. I have a bit of a toolkit I've been building out over the years and contains some base files and handy tools.

When building out bigger systems like this, I like to set up a solid way for managing design tokens. I use a variables.scss file which stores css custom properties of the tokens as a whole library. Those then get abstracted into a theme.scss file, where they are applied to semantic theme variables, like --button-color or --border-color. This allows for composable themes that are easy to change as the system evolves.

Working with our team of product marketers, copywriters, and my creative director, I created a content model that allowed us to store the content we needed and enable us to tell the stories we wanted. This content model included parts for managing the website itself, like pages and navigations, but it also had me modelling products, events, a blog, partner directory, podcast, release notes, customer stories, demo videos, and use cases. Leaning into the Structured Content mantra, we made extensive use of references that allows us to make sure our content is connected and updated everywhere as it's changed.

With our choice of Next.js for the frontend, we had really great options for handling our deployments and hosting, Netlify and Vercel being initial frontrunners. I didn't want to utilize our old Concourse CI pipeline Google Cloud set up as it was slow and cumbersome comparatively. As we were breaking ground on the build itself, Cloudflare had launched it's Pages product and as Enterprise customers already, it was free for our adoption - which was great. The only catch is that I'd have to make a Sanity plugin to allow us trigger builds with Cloudflare Pages. Luckily I was able to fork Nick DiMatteo's Vercel Deploy plugin and alter it to work with the Cloudflare specifics.

Having getting the design work from Whiteboard at the end of August, we were able to flip the switch on the new site at the end of October. I had onboarded 10 teammates onto Sanity which allowed them to publish content at their discretion, without any need for developer intervention.

Having an efficiently componentized system for our website we've been able to iterate and make changes quickly and cleanly. We also gained massively in time saved in our processes, going from an hour for a small copy change to make it to production to under 2 minutes. We also had the ability to instantly roll back to different versions of the site, as well as infinite staging environments that would build based on activity in the repo on GitHub. The site pulled in global theme data that would allow you to stage wildly different versions of the site, allowing for new home pages to be assigned along with different navigation structures.