A traditional CMS handles both sides: editors write in it and it builds the web pages. A headless one only manages the content and hands it over to whatever displays it: a website, a mobile app, a screen in a shop.
When it makes sense
- The same content must appear on a website and in an app.
- Editors need a proper interface and workflow, with roles and approvals.
- A development team wants freedom in how the front end is built.
When it is more than you need
- A small site whose text changes a few times a year.
- A single person edits everything and is comfortable with a simple tool.
- You would be paying for, securing and updating a second system for no gain.
Simpler alternatives
Content can live in files in the project, edited by the developer or through a small admin screen built for the few things that change. This is cheaper to run and has less to attack. The cost is that non-technical editors need that admin screen, which should be built or chosen deliberately.
The right question is not “do I need a headless CMS” but “who edits what, how often, and where does it appear”. Answer that, and the tool usually becomes obvious.