Content systems Kiwi insights
What a custom CMS content model needs before development starts
Model content types, relationships, editorial permissions, and validation from the work people need to do rather than from a page mockup.
A custom CMS should be designed around the information and editorial decisions it must support, not around the first set of page components. A page-first model often works until the same information needs to appear in another route, locale, channel, or interface.
Define the domain before the fields
Name the content types the organization actually manages, the attributes each needs, and the relationships between them. Content-modeling guidance from Sanity and Kentico describes this as organizing content types, attributes, and relationships so content can be managed and reused with purpose. Include editors and developers in the work: editors know the operational constraints, while developers need to understand the intended structure.
Design for real editorial tasks
- Who can create, review, publish, unpublish, and change each type of content?
- Which fields are required, constrained, localized, or linked to other records?
- Which content needs an owner, review date, or retirement decision?
- What needs validation to prevent a broken primary journey or misleading published claim?
Test the model with representative content
Create examples that include the awkward cases: incomplete entries, long titles, missing images, an expired offer, a new locale, and a changed relationship. If editors need to call a developer for normal changes, the model or workflow is incomplete. If unrestricted changes can break critical structure, the permissions and validation are incomplete.
Kiwi can help define and implement a content model that fits an agreed website scope. It does not recommend a platform solely from a feature list or claim that one architecture suits every publishing team.