The fastest way to slow down a product team is to make every content change a dev ticket. We fixed that.
This is a story about something unglamorous: content infrastructure. No user-facing features with clever names, no growth curves that make executives sit up straighter. Just a fundamental change in who can change what, and how fast. Which, it turns out, matters more than most teams realize until they’ve spent six months fighting over sprint capacity.
What the Problem Actually Looked Like
At Skillshare, discovery and marketing surfaces — landing pages, featured sections, promotional banners, category pages — were tightly coupled to the engineering release cycle. A marketing campaign wanted to update the homepage hero for a back-to-school push: engineering ticket. The content team wanted to test two different framings for a category page: engineering ticket. Someone wanted to fix a typo in a featured section: engineering ticket.
Every one of those tickets competed with platform work, creator tools, learner features, and bug fixes for the same engineering bandwidth. Some of them waited weeks. Some of them didn’t get prioritized at all, which meant either the campaign launched with stale content, or someone decided the test wasn’t worth the queue time.
This is a real organizational cost, but it’s diffuse and hard to measure. You don’t see “marketing couldn’t test that hypothesis” on a dashboard anywhere.
Builder.io and the Headless Approach
The solution was introducing a headless CMS layer using Builder.io. The concept is straightforward: decouple the content that lives on a page from the code that renders the page. Engineers build and maintain the components — the slots, the layouts, the rendering logic. Non-engineers fill those components with content directly, without touching code.
The “headless” part means the CMS doesn’t control the frontend presentation layer — the Skillshare frontend does that. Builder.io sits in between, handling the content modeling and the visual editor that non-technical teams use. Changes made in Builder.io update the content; the page renders correctly because the component structure is already there.
For Skillshare, this meant marketing and content teams could update landing pages, swap featured content, run promotional campaigns, and test different content configurations — all without an engineering ticket, all without waiting for a sprint.
🚧 Need more context: How many pages or surfaces were brought into Builder.io? Which teams were the primary users — marketing, content, product? Was there an onboarding process for teams adopting the tool?
The Experimentation Angle
Faster content changes aren’t just operationally better — they change what kinds of experiments are worth running. When a test costs three sprint cycles to set up, you only run tests you’re very confident about. When a test takes an afternoon, you can afford to be curious.
The Builder.io layer laid the infrastructure for easier A/B testing on content layouts and merchandising decisions: which featured classes convert better, which promotional framing drives subscription starts, how different category page structures affect learner exploration. None of that experimentation potential is accessible if you’re bottlenecked on engineering capacity.
🚧 Need more context: Were specific A/B tests run using the CMS infrastructure? Were there measurable conversion improvements connected to content experiments that the CMS enabled?
The Engineering Side of the Equation
One thing worth saying: this kind of project can feel like a downgrade from engineering’s perspective if framed poorly. “We’re building a system so you have to do less” is not motivating. The actual framing — “we’re taking routine content maintenance off your plate so you can focus on harder problems” — is different, and it’s true.
Engineering went from fielding a stream of low-complexity, high-interruption content tickets to building a system that handled those needs at scale. The ongoing maintenance burden dropped. The work that remained was more interesting.
🚧 Need more context: What was the before/after on engineering ticket volume for content-related requests? Was there a specific time-to-publish metric tracked? How many campaigns or content experiments ran in the first quarter after launch?