This is even easier then something like WordPress for them, and much simpler for me. WordPress deserves credit for its ease of use for non-technical people, however I don't view this as a good metric for what to choose for a website.
I deliver the _site folder as a finished product and put it on Cloudfront with HTTPS. That's about as simple and unbreakable as it gets. Customers can then pay a monthly retainer or occasional hourly rates for updates. If they want the source files to run the generator on their own machine that's fine too, but it costs extra.
The model isn't that much different from a wedding photographer.
Using a mac? I hope you've got xcode installed to give you command line tools. No, you can't get that to work without logging into your Apple account. Right, now just install these tools using homebrew. Oh, homebrew's giving some git error? Sorry, you're on your own. Got homebrew working? Right, better make sure you've got ruby and gem and python and nodejs installed. Still doesn't work? Oh, that's because you're missing redcarpet, just gem install redcarpet. It didn't work? Oh, guess I actually need a development version of ruby.
Moved to Linux? Good news, there's a jekyll package right there. Bad news is it's outdated and won't build your site. Time to install ruby and gem then use them to install jekyll. Didn't work? Oh, you don't want that version of ruby, you need the development version, gotta have the right files so you can compile things as they download.
So no, I don't recommend static site generation to anyone who isn't a veteran error-message-googler.
[1]: https://gohugo.io/
Obviously, bad SSG are bad, but not all of them are: any SSG worth recommending to the general public in exchange for money (i.e. recommending to your customers) is one that doesn't rely on the user first making sure their "tech stack" is set up properly: it just comes with a normal installer (even if that "installer" takes advantage of the OS it's running on to grab all the dependencies it needs for itself and uses a preinstalled scripting language to run the system under the hood).
And of course typically these still have a "this project is open source, click here for our git repo!" link that normal users will NEVER use, but power users are drawn to like moths to a flame. Their experience, however, is not what you're going to sell your customers =)
There's options like Netlify to use as CMS: https://github.com/netlify/netlify-cms
Hugo will run anywhere.
In Linux you don't need to install the distro's packaged version; source is where you should go.
There is an added difficulty, but it's not as painful as you make it seem.
https://cloudcannon.com / https://forestry.io/ / https://www.siteleaf.com/
With all of them you can set up nice content type templates and get your client to put structured content.
edit: formatting
However I'm still waiting for the right client project to come along to use it with as it's rare for someone to need a custom-built site and also the fairly limited features of a static cms.
Usually if they want a simple site something like Squarespace will be the quickest and cheapest option, whereas if they have any complex requirements, like migrations or integrations with other platforms, then an open source cms framework like Drupal is often a better starting point.
For a general site that's going to be maintained by a non-technical audience? Absolutely not. They need a WYSIWYG editor instead of markdown. "Deploy" for them has to be a "publish" button. Keep it simple with a self-updating WordPress on WPEngine or similar.
For API documentation sites, I use Jekyll and Slate all the time. They're going to be maintained by developers so markdown is easy. Version control is key. And syntax highlighting is important. We use Jekyll at Okta and it's easy but powerful enough to solve the big problems quickly and easily.
I've got a smallish piece of JS that gives the client a WYSIWYG editor, which speaks to Firebase.
When Firebase gets an update, it triggers a rebuild.
Best of both worlds.
I'm afraid not, but mostly because it's both simple, and fairly reliant on architecture.
Basically the process is:
Firebase authentication -> Content editable editor -> Firebase database update -> GitLab CI -> Pandoc & bash to update static site to latest Firebase -> Deploy to website
A real-world example would be the First Round Review (http://firstround.com/review/), designed by our studio (https://marquee.studio) and running on Proof.
I'll be doing a private release in few weeks for the beta subscribers.
Non-developer staff have been fine with this, editing Markdown files within the Github interface and adding the occasional PDF. If something doesn't look right on the test site, they can ask for advice.
The developer experience is great in static site generators such as Hugo, Gatsby, among others.
And finally, if your client needs to update content, you can use headless CMS such as Contentful, NetlifyCMS, Dato etc.
