[{"data":1,"prerenderedAt":26},["ShallowReactive",2],{"W6kDOHDuqY":3},{"id":4,"slug":5,"title":6,"excerpt":7,"meta_title":6,"meta_description":8,"page_content":9,"featured_image":17,"fields":18,"tags":20,"published":22,"published_at":23,"created_at":24,"updated_at":25},"c75b6334-d8d9-4680-ac09-c4b9225ccc74","notes/how-to-choose-a-headless-cms","How to Choose a Headless CMS","Once you have decided to go headless, which one do you pick? The questions I actually use to choose a headless CMS, and the feature-grid noise to ignore.","How to choose a headless CMS: the questions that actually decide the fit, from editor experience to content modelling, hosting, API and lock-in.",{"blocks":10},[11],{"id":12,"data":13,"type":16},"6804b443-93cb-4866-9acf-33fdb9028e63",{"content":14,"maxWidth":15},"\u003Cp>Once someone has decided they want to go headless, the next question lands within a minute. Which one do we use? There is a long list of headless content platforms now, they all have slick websites, and from the outside they look interchangeable. They are not. Picking the wrong one is the kind of mistake you feel eighteen months in, when the thing your business needs is the one thing your CMS cannot do. So here is how I actually help clients choose, based on having built on several of them and lived with the consequences.\u003C/p>\u003Ch2>First, be sure you need one at all\u003C/h2>\u003Cp>I am not going to repeat myself here, but choosing a headless CMS is the wrong place to start if you have not settled the earlier question. I have written separately on whether \u003Ca href=\"/notes/is-a-headless-cms-overkill-for-a-small-business\">a headless CMS is overkill for a small business\u003C/a>, and on \u003Ca href=\"/notes/headless-cms-vs-wordpress-for-a-small-business\">headless versus WordPress\u003C/a>. Read those first if you are still deciding. This piece assumes you have decided headless is right and you are staring at a shortlist wondering how to tell them apart.\u003C/p>\u003Ch2>Ignore the feature lists\u003C/h2>\u003Cp>Every vendor has a feature grid, and they all tick the same boxes. Content types, an API, roles and permissions, webhooks, image handling. Comparing those grids tells you almost nothing, because the boxes are ticked to different depths and the grid never mentions the things that go wrong. I judge a headless CMS on a handful of questions that actually decide whether you will be happy with it in two years.\u003C/p>\u003Ch2>Who is going to edit the content\u003C/h2>\u003Cp>This is the first question and most people skip it. The developers pick the CMS on API design, then hand it to a marketing person who finds the editing experience baffling. Go the other way round. If non technical people will update the site every week, the editor experience is the most important thing you are buying. Sit the person who will actually use it in front of a demo and watch them try to add a page. Some headless CMSs give editors a genuinely nice interface with live preview. Others treat editing as an afterthought and assume a developer is always in the loop. Neither is wrong, but you need to know which one you are buying and whether it matches who will use it.\u003C/p>\u003Ch2>How rigid is the content model\u003C/h2>\u003Cp>The whole point of headless is structured content: your content lives as clean, reusable fields rather than a blob of formatted text. But platforms differ a lot in how they let you model it. Some are strict and opinionated, which keeps things tidy but fights you when your content does not fit the mould. Others let you build almost anything, which is powerful and also enough rope to make a mess. Sketch out your two or three most awkward pieces of content, the ones with repeating sections or relationships between them, and check the CMS can model those cleanly. The easy pages are easy everywhere. The awkward ones are where platforms show their true shape.\u003C/p>\u003Ch2>Hosted or self-hosted\u003C/h2>\u003Cp>This is the big fork in the road. Hosted platforms run the CMS for you, you pay a monthly fee, and you never think about servers or updates. That is convenient and it is the right call for a lot of businesses. The trade-offs are cost that scales as you grow, pricing tied to things like user seats or API calls, and less control over where your data lives. Self-hosted and open source options run on your own infrastructure. You own everything and there is no per-seat bill, but now you or someone you pay is responsible for hosting, security patches and upgrades. There is no universally right answer. There is only the right answer for a business with your budget and your appetite for looking after infrastructure.\u003C/p>\u003Ch2>The API you will actually live in\u003C/h2>\u003Cp>Your front end talks to the CMS through its API all day, so the shape of that API matters more than any feature. Some serve content over a query language that lets the front end ask for exactly what it needs in one request. Others give you more traditional endpoints. What I look for is whether fetching the content for a real page is simple or whether it takes five chained requests and a lot of glue code. Ask your developer to build one real page against a trial account before you commit. An afternoon of that tells you more than a month of reading documentation.\u003C/p>\u003Ch2>How hard is it to leave\u003C/h2>\u003Cp>Nobody wants to think about the exit when they are signing up, but lock-in is exactly what bites later. Check two things. Can you get all your content out in a clean, structured format whenever you want, or is it trapped behind an export that loses half the structure? And is your content model portable, or is it wrapped up in one vendor's proprietary concepts so tightly that moving means starting over? A platform you can leave is a platform that has to keep earning your money. That is a healthier position to be in than being stuck.\u003C/p>\u003Ch2>Who fixes it when it breaks\u003C/h2>\u003Cp>Every platform breaks or confuses you eventually. With a hosted product you are relying on their support and their status page. With open source you are relying on the community and whoever you have on call. Neither is better in the abstract, but you should know the answer before you need it. A small business with no developer is far safer on a well supported hosted platform than on a self-hosted one that goes quiet the moment something goes wrong at nine on a Friday.\u003C/p>\u003Ch2>Where the well known names sit\u003C/h2>\u003Cp>Without turning this into a review that goes out of date next quarter, the market roughly splits three ways. There are polished hosted platforms that charge a subscription and do the running for you. There are open source products you host yourself, which trade a monthly bill for taking on the infrastructure. And there is WordPress used as a headless back end, which can be a sensible middle path if your team already knows it and you just want a faster front end. Any of these can be the right answer. The winner is the one that fits how your content is shaped and who is going to look after it, not the one with the best landing page.\u003C/p>\u003Ch2>Where I land\u003C/h2>\u003Cp>When I help a business choose, I start from the editor and the content, not the technology. Get those right and most of the shortlist falls away on its own. I will happily talk anyone through their own setup honestly, including telling them when the CMS I build on is not the right fit for them, because a platform someone regrets is no good to either of us. If you want a straight opinion on which direction suits your business rather than a sales pitch, that is the kind of thing I \u003Ca href=\"/services\">help with\u003C/a>, and you can see how I think about the trade-offs on the \u003Ca href=\"/platforms\">platforms\u003C/a> page.\u003C/p>","lg","wysiwyg","",{"author":19},"Headless Digital",[21],"headless",true,"2026-09-07T08:00:00+00:00","2026-07-13T08:52:39.078403+00:00","2026-09-07T08:00:01.653837+00:00",1789027255617]