Hey, we're in a similar situation and we just evaluated a bunch of different options. Just wanted to share some findings.

One, in terms of integration, if you're considering headless you probably already are thinking of a decoupled solution (meaning frontend and CMS are separate anyhow). In that case, it might help to think about the CMS as just another generic API that your frontend has to speak to instead of "integrating" with via bespoke SDKs.

These days, many vendors offer GraphQL output for their content delivery APIs, and that's really easy for Gatsby or Next.js or graphql-request or node-fetch to consume. The resulting shape (object schema) you get back as a response is easy to map into component trees and iterables. Many (most?) headless vendors offer GraphQL endpoints now, and while it's not perfect, for most pages it'll be easier than having to join together multiple REST calls (like one call for posts, another for authors, a third for tags, a fourth for related items). GraphQL makes that all one API call returned as a nested JSON.

Among headless options, there were initially 20+ vendors to choose from (this site has a list: https://cms-comparison.io/). As the primary dev, I did a first pass and eliminated a few right off the bat that I didn't think would fit our needs. Then we asked the other stakeholders to participate in a pretty exhaustive weighted features comparison (https://airtable.com/shrDPlmk7R3B4ddO1), having each stakeholder compare features across each CMS, then weighing each feature by their importance to our project. While we didn't choose the final winner this way, it did help narrow our initial list of 20+ options down to a more doable 2-4 finalists. We built functional prototypes (choosing a complex enough page to showcase the CMS's capabilities) and demoed them to the stakeholders and began contract negotiations.

We learned a lot from that process for our own needs, and I'd encourage you to pick a few and run a similar analysis just for yourself and your client, based on their needs. For example, will they require deeply nested content models (like a page that contains a section that contains an accordion that contains a WYSIWYG that contains a paragraph with a CTA button that opens up a modal that they can define in the CMS).

Some of the options are better at handling that sort of thing (GraphCMS, Contentful), but that comes with tradeoffs in other parts of the editor experience. It seemed in our evaluation that the CMSes that were the most flexible in terms of nestable content models were also the ones that didn't offer as good a page composition experience, as in being able to visually drag and drop things around a page (move the accordion above the hero) in an intuitive way. The market is still trying to figure out how to best do their UIs and UXes. Some of them treat every field and model as equivalent primitives, meaning you build everything up from the deepest nested layer (usually something like a "button" or "image with caption") then add containers within containers on top of that. But that quickly becomes visually and mentally overwhelming for the editors, who usually think about pages not in terms of nested schemas but the functionality that they want to add. Some of the other options, then, purposely avoid the "everything is a model" design and break things down into pages, posts, blocks, etc. (DatoCMS, Storyblok, ButterCMS). In any case, it's worth poking around a few of them and trying to model a complex page or two in their schema builder (model editor) to see if the resulting page would be easy enough for a non-dev editor to use and edit.

Among open source packages, to my overwhelming surprise, Wordpress with Advanced Custom Fields (