Argument against Wordpress for clients

My partner and I started playing with Grav last week and really like it so far....speed is sooo good :) And so I'd like to offer building an upcoming web project using this framework rather than Wordpress.

The advantages of using a flat cms are clear. I'm just wondering if there some particular areas you've had to communicate with clients to feel more comfortable with Grav versus Wordpress.

How do you talk about flexibility with this platform? My clients always are concerned with ability to make modifications and scale.....somehow scale seems to be a buzzword everyone asks

Modifications are markedly harder with a CMS like Grav and static-site generators, as virtually all settings are kept in templates and css. Whilst you could allow for a lot of variety through frontmatter, too much of it would be cluttered enough that you might as well teach them code or device an interface for it - essentially what full-fledged CMS like WordPress do.

My main arguments for using Grav on medium-to-large scale projects are the following:

1. Reading and writing Markdown is incredibly easy for the end-user, and there is a plethora of editors which elegantly allow them to focus on writing, formatting, and proofreading. This takes a lot of unecessary complexity away from content-creation, and allowing them a variety of templates to display the content through is sufficient.
2. Organizationally pages are well-structured and easy to understand for end-users. You write a page-mdand place it in about and you'll get /about/ displayed with the page-template.
3. To the degree that any end-user wants to make simple color customizations, tell them to use a gener ator like Coolors and apply that scheme in a specific css/scss file. Anything more than that and they will need to actually know css, or get customization help.

Scale is a different issue. If we imagine the amount of pages to be in the thousands, then the flat-file structure would be a more painful endeavor than a database. A database can easily be transferred as a single unit, whilst transferring thousands of folders and files takes more time. In an ideal world I would have the combination: For websites with pages exceeding 500, I would flat-file everything apart from blog-like posts. They are better handled in a server-less database-like file (single, not plural).

Thanks so much Gingah for all this input! This is really helpful and definitely has me thinking of how we can communicate these points. We just went through some Grav lessons to learn about creating modules....actually I can see how Grav can allow someone to building a page up/layouts or adding a section after the project is delivered. Most of our clients don't code and so we're trying to figure out how much freedom we can allow and where to draw the boundaries.