The move to headless was game-changing for developers, but it did cause issues for content editors. We are working on solving those problems today, but they are worth noting.
Traditional (or "coupled") CMS often come with WYSIWYG (what you see is what you get) editors that allow content editors to see exactly how their content will look on the site as they're creating it.
In a headless CMS, this feature may not be available or may be limited, as the frontend presentation is completely separated from the content management backend. And, in many cases, the content may be published in multiple ways to multiple frontends.
Fortunately, tools like Stackbit are actively working on solving this problem, which we discuss more in the next chapter.
Content editors may find it challenging to understand the context of their content. They might not know how content will be displayed on different devices or platforms, making it hard to optimize for specific use cases. Visual editors are also helping to ease this pain.
Most content delivery services have API limits. Because of this, and because of the benefit of pre-rendering content, you will often have to wait for a build to finish before published content is available on the live site.
This can mean a long wait for sites at scale.
These content sources are technical products, typically being used by non-technical folks. Adding fields or adjusting layouts on a page almost always requires the use of a developer.
There are ways to overcome this, but they often result in more complex and slower editing processes. This is yet another problem that visual editors are aiming to solve.