Model the content, not the pages
Most headless CMS projects fail at the content model, weeks before anyone notices it in the interface.
The failure looks like this: eighteen months after launch, the marketing team is pasting HTML into a rich text field because the model has no type for what they need. Nobody made a bad decision. The model described the pages that existed on launch day rather than the kinds of thing the company publishes.
Start from the noun, not the layout
A case study is a thing. It has a client, an industry, an outcome, a set of metrics, and a quote from a named person. It appears on its own page, in a grid on the services page, and in a carousel on the home page — but those are three views of one noun, not three content types.
When the model is built from nouns, adding a fourth view is a template. When it is built from pages, adding a fourth view is a migration.
Two tests before you build the schema
- Name a change the marketing team will plausibly want in a year, and check whether it needs a developer
- Ask an editor to add one real item using only the field labels, with nobody helping
The second test is brutal and worth running before the schema is final. Field labels written by engineers describe storage. Editors need labels that describe the decision they are making.
On rich text
One long rich text field is where content models go to die. It is unqueryable, unstyleable, and it becomes the escape hatch for everything the model failed to anticipate. Use a block list with a small number of real block types, and treat every new block type as a deliberate decision rather than a convenience.
If editors are pasting markup, the content model has already failed. The interface is just where you noticed.