One content model, three brand sites, zero duplicate entries
A headless CMS with one structured content model feeding three separately branded publications through the same API, so an article is written once and syndicated everywhere it belongs.
What the engagement involved
- Industry
- News & Digital Publishers
- Duration
- 10 weeks
- Cooperation model
- Fixed price, phased
- Services
- Content modelingHeadless CMS buildEditor workflow
- Integrations
- StripeSendGridSegmentSentry
- Technologies
- Next.jsTypeScriptHeadless CMSGraphQLIncremental static regenerationTailwind CSS
- Team
- 1 Project lead1 Product designer2 Frontend engineers1 Backend engineer
Client name withheld under NDA. Engagement details are shown to the extent our agreement permits.
What we were brought in to do
Three separate CMS instances ran for three branded publications, so a shared story had to be retyped into each one, and updates never stayed in sync across sites.
A publisher running three branded titles from one editorial desk, each on its own CMS instance chosen at a different time by a different team. Shared wire copy and desk-written features were typed into all three. The engagement was commissioned after a correction to a factual error made it onto one title and not the other two, which was noticed externally.
Content Platform Engineering
Where the old way broke
- 01
Editors maintained the same wire-service and shared-desk content three separate times, formatting drifted between sites, and a correction on one publication rarely made it to the other two.
Content was modeled as pages, so a shared story was three unrelated pages that happened to contain the same words. Nothing linked them, which meant a correction had no mechanism to propagate and depended on an editor remembering. Formatting drifted for the same reason: three sets of markup edited independently over four years.
We modeled content as structured, reusable entries (articles, authors, topics) delivered through one headless API to all three branded frontends, with per-brand presentation layered on top and a single copy of the content underneath.
Write once, syndicate
An article is authored once and appears wherever it belongs, with no duplicate entry.
Content is modeled as structured entries (article, author, topic) with references between them, not as pages of markup, so an article can appear on three brands without being copied three times. An author update propagates everywhere their byline appears. The model refuses presentation fields entirely, and that discipline is what makes syndication actually work instead of merely possible on paper.
- Structured entries with references, not pages of markup
- One article syndicated without duplication
- No presentation fields in the model, by design
The article type's twelve fields and which title reads each: one publication reads nine and crops to a square, the body is shared instead of duplicated, presentation fields are refused, and one author record gives full-name bylines on two titles and first name only on the third.
Presentation on top
A ferry timetable corrected once in the body, with its correction note, live on both sites that carry it eight seconds later while the third never ran it, beside each title's own presentation layer: type scale, crop, byline rule and the fields it reads.
Per-brand styling layered over shared content, never duplicated beneath it.
Each brand is a presentation layer over the same GraphQL API: its own type scale, palette and component choices, resolved at build time and regenerated incrementally when the content behind it changes. A brand can restyle without touching content, and content can be corrected once and appear corrected on all three within seconds, with no separate edits.
- Three frontends over one GraphQL API
- Per-brand styling resolved at build, regenerated incrementally
- A correction lands on all three brands within seconds
One editor workflow
A single review and publish flow with per-brand controls, replacing three separate CMS habits.
One editorial workflow (draft, review, schedule, publish) with per-brand release controls sitting on top, so a piece can go live on one brand and stay embargoed on another without becoming two records. Editors moving between brands work the same way in each, which was most of the point: three CMS habits had been producing three sets of inconsistencies.
- One draft-review-schedule-publish flow for all three brands
- Per-brand release control without splitting the record
- Editors work identically whichever brand they're on
One draft, review, schedule and publish board for every title, and one record released per title: scheduled on one publication, embargoed on another and not carried by the third, without becoming a second entry.
What we built together
- 01
Modeled articles, authors, and topics as structured, reusable content types
Editors validated the model against real stories before any frontend work, since a model that can't express what the desk writes is one they route around.
- 02
Built a shared editor workflow with per-brand publishing controls
One draft-review-schedule-publish flow serves all three titles, with per-brand release control so a piece can go live on one and stay embargoed on another.
- 03
Delivered content through one API to three independently branded frontends
Three frontends read one GraphQL API, with per-brand styling resolved at build and regenerated incrementally when the content behind it changes.
- 04
Migrated existing content from three CMS instances into the shared model
Migration ran as its own phase, because moving four years out of three instances is where the real work and the accumulated divergence both were.
Operational results after launch
0
Duplicate content entries
−90%
Cross-site correction time
14
Editor hours saved weekly
Duplicate content entries is structural: an article is one record, so the count is zero by construction, not by measurement. Cross-site correction time compares the same operation before and after. The fourteen hours weekly is the editorial team's own estimate of retyping removed, and is reported as their figure.
Client name withheld under NDA. Figures are approximate, drawn from the engagement’s own reporting.
Phase by phase
Phase 1: Model
Content as structure
Modeled articles, authors, and topics as structured reusable types instead of per-site pages.
- Content model
- Taxonomy
Phase 2: Workflow
One way to publish
Built a shared editorial workflow with per-brand publishing controls and review states.
- Editorial workflow
- Role matrix
Phase 3: Deliver
Three frontends, one API
Delivered content through one API to three independently branded frontends.
- Delivery API
- Three frontends
Phase 4: Migrate
Three instances into one
Migrated existing content out of three CMS instances into the shared model, reconciling conflicts.
- Migrated corpus
- Conflict log
- Editor guide
Merging City life into Retail: 214 entries moved and 214 redirects created with no site needing a manual edit, beside the migration conflict log from three CMS instances and each desk reading its own migrated content before go-live.
About our collaboration
- 01
A cross-functional team of 4 worked on a fixed price, phased basis over 10 weeks, covering Content modeling, Headless CMS build, Editor workflow. We ran a standing mid-week checkpoint and written decisions in place of status meetings. Nothing shipped that they had not seen working first.
Ten weeks, phased, with migration as its own phase instead of a closing step. Moving four years out of three CMS instances is where the real work sat, and where those years of undecided divergence in style, taxonomy and byline conventions finally became visible to anyone. Each brand's frontend went live only once its migrated content had been read by its own desk.
What we'd carry into the next one
Duplicate entry was a symptom; the cause was content modeled as pages instead of as things.
Editors were retyping because there was nothing to reference: pages can't be shared, only copied, and every copy is a correction waiting to be missed.
Layering brand presentation over shared content is what made a third brand cheap to add.
Presentation on top, with one copy of the content underneath, is what makes the fourth title a frontend instead of a project. That's the property the publisher was buying.
Migration surfaced years of quiet divergence between the three sites that nobody had cataloged.
The migration audit found style, taxonomy and byline conventions that had diverged without anyone deciding to. Nobody had ever had cause to compare the three.
One entry, three publications
Each title reads what it needs. A correction is made once.
Switch between the three publications to see which fields each one reads and how it presents the same record, then correct the date once and watch every title pick it up. Use the arrow keys once a tab is focused.
One entry · art_7KL4 · carried by all three titles
West channel to reopen to leisure craft next month
Fields this title reads
12 of 12
- Headline
- Short headline
- Standfirst
- Body
- Hero image
- Image caption
- Author
- Topics
- Location
- Published at
- Related entries
- Correction note
Fields a title doesn't read are simply ignored by its frontend. Crop and byline rule belong to the title, not the entry: the model holds no presentation fields.
West channel to reopen to leisure craft next month
Leisure craft return to the west channel once dredging finishes.
By Morwenna Treloar · Saltmarsh Quay
The harbour master confirmed the channel will reopen to leisure craft on 2 October, once the last dredging barge has cleared the moorings.
Correct the date once and watch each title pick it up. Illustrative timings (Harbour Post 4.2s, Examiner 5.6s, Tidal 6.8s), inside the “within seconds” the desk sees. Not measured.
From a story written once to every title that carries it
Presentation sits on top of shared content instead of being duplicated underneath it, so the only place a story exists is the one entry the desk edits.
- 01 · DeskOne editorial workflowDraft, review, schedule, publish for every title, with per-brand release control that never splits the record in two.
- 02 · ModelArticle, author, topic entriesStructured entries with references between them. The model refuses presentation fields, so nothing ties an entry to one title.
- 03 · APIOne GraphQL APIAll three frontends read the same entries. An article on three titles is one record, so duplicate entries are zero by construction.
- 04 · BuildIncremental regenerationPer-brand styling resolved at build; pages regenerate incrementally when the content behind them changes, so a correction lands within seconds.
- 05 · TitlesThree branded frontendsEach title owns its type scale, palette and components. A brand restyles without touching content, and a new title is a frontend, not a project.
Same facts on every title
Corrections, embargoes & a migration read before go-live
A correction has one place to go
A shared story is one entry, not three pages that happen to hold the same words. The fix is made once and every title carrying the entry regenerates from it, so nothing depends on an editor remembering the other two.
Embargo without a second copy
Release is set per title on the same record, so a piece can go live on one publication and stay embargoed on another. Holding it back never means duplicating it, so there's no copy to drift.
Nothing live that its desk hasn't read
Migration ran as its own phase and surfaced years of diverged style, taxonomy and byline conventions. Each title's frontend went live only once its migrated content had been read by that title's own desk.
Running several titles from one desk, and still correcting the same story more than once? Scope your build in 3 minutes.
Scope your buildNearby engagements
Web PlatformsA writing desk where the manuscript never leaves the machine
A desktop notebook built on Electron, where documents live on disk, the editor is a real rich-text surface, and the AI assistant reads only what the writer hands it.
Book Publishing · 14 weeks
AI & AutomationLong text becomes narrated audio, and the job tells you the truth while it runs
A production tool that pulls text out of a source, narrates it, and reports honestly on a job that takes minutes, without pretending to be instant.
Media & Publishing · 12 weeks
Web PlatformsTwo billing models in one product, and neither one pretending the other doesn't exist
A content platform sold both by subscription and as a lifetime deal, where a redeemed code and a monthly plan resolve to the same entitlement, with no parallel systems.
Media & Publishing · 18 weeks
Let's talk
Running a large platform, shaping a first MVP, or getting a product ready for a funding round? Tell us where you are. We'll shape the process around it, and stay with you after launch.
