The CMS question has a reputation for being complicated. It is not, once you remove the parts that are actually just preference or habit.
The complication usually comes from conflating two different questions: do you need content to be editable by non-developers, and do you need a CMS to make that possible? Those are separate questions and they have separate answers.
The actual question to ask
The right question is not "should we use WordPress?" or "should we use Webflow?" It is this: who will be changing the content, and how often?
If the answer is "a developer, a few times a year" — you probably do not need a CMS. A static site with a clear file structure and good documentation is cheaper to run, faster to serve, and has fewer moving parts that can break.
If the answer is "a marketing person, every week" — you need something with a visual editor. How capable that editor needs to be depends on how much the content varies.
If the answer is "nobody has looked at the website in eight months" — stop and think about whether the site is solving a real problem before choosing how to build it.
Where WordPress still makes sense
WordPress has a reputation that ranges from dated to actively hostile, depending on who you ask and what experience they have had. Our view is more boring: it is a reliable choice when two things are true. First, the client has a team member who will actually use the CMS to update content regularly. Second, the hosting and maintenance overhead is understood and accepted.
The mistake is recommending WordPress for a client who says they want to be able to "edit things easily" but whose site content has not changed in a year and is not going to change in the next one. That client is paying for CMS complexity they are not using.
Headless is not the answer by default
We have built headless setups — typically Sanity or Contentful as a backend, with a custom frontend. They make sense in specific circumstances: when the content needs to appear on multiple platforms (site, app, kiosk), or when the content model is complex enough that a custom schema is genuinely easier to work with than WordPress custom fields.
For a standard marketing site, headless adds cost and complexity without solving a problem the client actually has. We have seen three headless projects in the last two years where the actual update frequency was quarterly and the content structure was five page types. A simpler tool would have served them better.
The framework we use
Static site if: content is updated by developers, updated less than monthly, or the site is mostly fixed-structure pages without variable content types.
WordPress if: a non-developer needs to update content, the update frequency is weekly or more, and the hosting overhead is acceptable.
Headless if: content appears across multiple platforms, or the content model is genuinely too complex for WordPress to handle cleanly.
In practice, most briefs we receive call for static or WordPress. The headless option comes up perhaps twice a year.