The most expensive mistake in any Drupal project is not a bug, a slow query, or a missed deadline. It is a content model that does not match how the organization actually works. Once the wrong structure is in production, every page, every editor habit, and every downstream integration is built on top of it, and changing it later is far more expensive than getting it right the first time.
The tragedy is that the conversation that would have prevented all of it takes about two days. It is the conversation most projects never make time for.
What a content model actually is
Forget the Drupal vocabulary for a moment. A content model is the answer to a very practical question: what kinds of things live on this website, and what does each one know about itself?
A job board knows about jobs. A job has a title, a company, a location, a salary range, a contract type, an application deadline, and a description. A university knows about courses. A course has a name, a faculty, a level, a duration, a language of instruction, a list of prerequisites, and an enrollment window. A specialist publisher knows about articles, authors, and topics, and the relationships between them.
In Drupal terms, this is where you decide on content types, fields, taxonomies, and the relationships between them. It is the plan the whole site is built on. Every one of those models will be wrong on the first attempt unless somebody asks the right questions out loud.
The questions nobody asks
On every new project we insist on a period of content modeling before any design or development starts. It sounds unglamorous. Clients sometimes resist it (we have paid for design, can we see some pages?) and we always push back. This is the work that decides whether the rest of the project is pleasant or painful.
The questions we ask are simple, but they are rarely on a project brief.
Who enters this content, and with what information in hand? A marketing team writing long-form articles works differently from a technical team publishing product specs from a spreadsheet. A press release has a different life cycle from a product page. The model has to match the input, so we start with the editorial workflow rather than the design. The fastest way to learn it is to sit with the people who will actually use the CMS and ask what they create most often, what takes them the longest, and what they would like to reuse. Their answers shape the content types far more than any wireframe does.
What connects to what? If an event has a speaker, and a speaker has a biography, and the biography appears on three pages, is that one piece of content reused or three copies that can drift? The answer determines whether your editors curse your site six months from now.
What changes often, what never changes? A content model should distinguish between the stable parts of your information architecture and the parts that move weekly. Both need to exist. They should not be in the same place.
What has to be translated, and what is universal? Multilingual organizations almost always discover too late that some fields should be shared across languages (a product code, for example) and others should not (a product description). The correct answer has to be wired in from day one, not retrofitted.
What else in your business depends on this content? Feeds, exports, integrations, reporting dashboards, newsletters, print materials. If any of those downstream consumers need your content in a specific shape, the model has to respect that shape. Discovering it late can mean re-entering a large amount of content by hand.
A few rules we follow
After a good number of Drupal projects, we have settled on a handful of modeling rules that prevent the most common mistakes.
Separate structure from presentation. A "featured" flag should not be a content type. It should be a boolean field or a taxonomy term. Content types represent fundamentally different kinds of content: an event and an article are different types. An article and a featured article are the same type with one field.
Prefer entity references over duplicating content. If two content types share the same author information, do not create author fields on both. Create an author entity and reference it. When the author's biography changes, it updates everywhere at once.
Name fields by meaning, not by appearance. A field called "Sidebar text" breaks the moment you redesign and remove the sidebar. A field called "Summary" works wherever it appears. Field names should describe what the content is, not where it goes.
Plan translation from day one. If there is any chance the site will be multilingual, enable translation on content types and fields before the content is created. Adding translation to an existing model after the fact is painful and error-prone.
The hidden cost of overly flexible layouts
Layout Builder and paragraph-based approaches give editors a lot of freedom. They can arrange components, add columns, and build a custom layout for every page. That sounds ideal until you see what it tends to produce in practice: every page looks a little different, brand consistency erodes, and editors can spend real time rebuilding the same layout, often less well than a template would, before each page goes live.
We tend to prefer structured content with a narrower set of layout options. An event page has a defined structure: title, date, location, description, speakers, registration link. The editor fills in the fields and the template handles the layout. It is quicker for editors, more consistent for the brand, and easier for developers to maintain. Flexibility is not always a feature. Sometimes it is a burden dressed up as autonomy.
Test with real content before launch
The last and most important step is to fill the site with real content before you finalise the model. Not lorem ipsum: real content from the client's existing site, or their first draft of the new content. Real content reveals problems that placeholder text hides: titles that run too long, descriptions that need rich text, images with unexpected proportions, and relationships that have to work in both directions. Time spent testing the model with real content is some of the best-spent time in the whole project, because it surfaces the corrections while they are still cheap to make.
What a well-modelled site feels like from inside the organization
The payoff for getting this right is the thing clients tell us about most, years after launch. It almost never sounds technical. It sounds like this.
"My team can publish an event in three minutes now. It used to take fifteen."
"When we launched in French, we did not need to redo anything. The content just worked."
"Our newsletter platform pulls the featured articles automatically every Monday morning. Nobody copies anything anywhere."
"When we added a new product line, we did not need to call you."
Those outcomes are not the result of clever code. They are the result of a content model that understood the organization before the organization fully understood itself.
If your current site hurts to edit, this is almost certainly why
If editors on your team complain about the CMS ("I can never find the right field," "I end up editing HTML," "I have to paste the same thing in three places"), the CMS is almost never at fault. The content model underneath it is. The good news is that a content model can be audited, and many of the issues it creates can be fixed without a full rebuild, if someone who has done this before looks at it with fresh eyes.
If the site in your head is the one you wish you had, with editors who move fast, integrations that just work, and content that flows everywhere it needs to go, tell us what you are trying to run. The first conversation is about the shape of your organization, not the shape of your Drupal site.