The CMS vendor decision gets most of the attention. The content model, how content types relate to each other, what's a reference versus a duplicate, what's reusable versus one-off, decides more about how painful the next two years of editing actually are, and it's worth a checklist of its own, independent of which tool ends up running it.
Model relationships as references, not duplication
If the same piece of content, a product spec, an author bio, a legal disclaimer, could reasonably appear in more than one place, it should be stored once and referenced, not copied into every record that uses it. Duplication is invisible at launch and expensive the first time that content needs correcting and the correction has to be hunted down across every copy instead of made once.
Separate reusable blocks from one-off page content
Most sites have a mix of highly reusable content (a call-to-action block, a testimonial, a navigation item) and genuinely one-off page content that will only ever appear once. Modeling both the same way, usually by making everything page-specific, means a reusable block can't actually be reused without copy-pasting it, which is duplication by another name.
Plan localization and versioning before they're needed
Even a single-language, single-version launch benefits from deciding early which fields are candidates for translation and whether content needs draft/published states or revision history, because retrofitting either into a schema that didn't anticipate it usually means restructuring content types and migrating existing records. The decision costs little made early; the gap costs a migration discovered late.
Design for the API shape your frontend actually needs
A content model designed in isolation from the frontend that consumes it tends to drift from what the frontend actually needs to query and render, the same problem a commerce backend has if it's designed from a spec document instead of the frontend's real requirements, covered from the commerce side in frontend as source of truth. Reviewing the content model against real frontend queries, not just against "does this represent the content correctly," catches shape mismatches before they're expensive to fix.
Starting a content model and want a second pair of eyes before it's locked in?
Share your content types and the relationships between them. We'll flag the duplication, the missing references, and the gaps that tend to turn into a migration later.
Talk to an engineer →The rule
Treat the content model as the real architecture decision, separate from and prior to the CMS vendor choice. Reference instead of duplicate, split reusable from one-off content deliberately, decide on localization and versioning needs before they're urgent, and validate the model against what the frontend actually needs to query. Getting this right once is far cheaper than migrating a content model that grew organically into a mess. For common mistakes specific to one popular platform, see five content-model mistakes that make Directus painful later. We design content models like this under headless CMS and Directus development engagements.