A client came to me with a brief that sounded simple: their pricing page had to always match what their backend actually sold.
More than 40 offers across three product lines, and the catalogue updates in real time. A configuration can be listed in the morning and gone by the afternoon. Someone was expected to keep a web page in step with that by hand.
That is not a discipline problem. It is just not possible.
An AI agent does not solve it either. I could point one at the project with the Framer CLI and have it make every edit perfectly. It would still have to be told when. The bottleneck was never how fast the edits get made. It was noticing that they were needed.
So the pricing page stopped being content.
I used Framer's CMS API to turn it into a rendering of the product itself. A service reads the client's inventory on a schedule, updates the CMS collections, and republishes the site. When nothing has changed, nothing is published.
The obvious way to build this is a code component that calls the API and renders the list. It works, and it costs you Framer. The design moves into code, the data is trapped in that component, and nothing else on the site can reach it.
Through the CMS, none of that happens. The offers are ordinary collection items. Cards are designed on canvas and changed by anyone on the team. Every spec is stored twice, once as the sentence a visitor reads and once as a number, so filtering and sorting are native. The same collection feeds anything else that needs it.
There is no static copy of a price anywhere on the site to forget about. That is the actual deliverable.
None of this is specific to servers. The same shape fits any collection already authoritative somewhere: catalogues from a store backend, job openings from a hiring tool, listings from an agency CRM.
The test is simple. If anyone on the team is copying values from one screen into another, that content should not be typed into the CMS. It should be mirrored into it.
