Static Site Generator (SSG) as a Free Squarespace Alternative?

One feature SSGs are missing is email contact forms. Some of them use Netlify forms https://www.netlify.com/platform/core/forms/ - 100 submissions per site /month ($19+ when exceeded). https://docs.netlify.com/accounts-and-billing/billing-faq/

Hugo's Piko theme uses FormSubmit.io (free) or Fabform.io ($5/mo). But I haven't tested that to understand how well it works and why/how it's free.

Hugo's Tella theme uses getform.io -- https://github.com/opera7133/tella/issues/63 (50/mo).

250/mo for free and $8/mo for unlimited with https://web3forms.com/ is the best I've seen so far _(besides the completely free one which I'm not sure about)_.

I haven't seen any of them mention using an SMTP.

I saw these *HTML templates* https://html5up.net/ recommended on another forum, but I would think they’d require more technical knowledge to use/customize than an SSG. They’re all pretty elaborate too. None are basic business or personal type websites.

# Wordpress:

I created a basic, free WordPress site some years ago when I was trying to set up a blog and I found it difficult to use and opted instead for Blogspot. However, I have more experience & knowledge now, so self-hosted Wordpress might be an option.

When I looked into Wordpress I was comparing the ".com" options (wordpress.com/pricing) with Squarespace, and they were more expensive. Now that I'm more familiar with hosting my own linux web server, I could probably use the ".org" and host on a $5-10/mo server but *I get a lot of traffic on my business site (_can reach 1m+ views in a month_) and I'm not sure how good/costly a server I'd need to keep it running*.

I saw *Oxygen Builder* recommended as a "Squarespace-type UI" for Wordpress, and I watched some of the tutorials (oxygenbuilder.com/tutorials) and it seems like a decent option for a one-time $130 fee. But still not static.

I saw someone using the https://generatepress.com/ WordPress theme for their website https://servermanager.guide/about. It looks like the premium $44/yr option may be similar enough to Squarespace.

It looks like you can also install wordpress on your PC and use plugins to output static sites. A limiting factor may be finding free/cheap plugins that make it as easy to edit as Squarespace. And I don't see a way to get contact/email forms working.

# Flat CMS options:

I found this [10 Best Flat CMS for Lightweight Websites - https://www.hongkiat.com/blog/flat-cms/] which lists *Grav* at #1. I checked out Grav and it's purely markdown and has nice templates (_Open Publishing Space, Agency, Deliver Site_) https://getgrav.org/downloads/skeletons. So that might be the best option. The Agency template has a *contact form*, but [looking at the code](https://github.com/getgrav/grav-skeleton-agency-site/blob/de...) I don't see how it's being submitted/sent/emailed.

I found this page - https://learn.getgrav.org/17/forms/forms/example-form - which looks like it can utilize any SMTP - https://github.com/getgrav/grav-plugin-email/blob/develop/RE.... But that, the installation instructions, and [the webhosting section](https://learn.getgrav.org/16/webservers-hosting) all indicate that it's not a static site that you can upload to Netlify. But it still seems like a cheap and user-friendly alternative to Squarespace.

It looks like Grav has a [static generator plugin](https://getgrav.org/downloads/plugins) (and another one called [blackhole](https://github.com/barryanders/grav-plugin-blackhole)). If you can install php on your PC you can probably use Grav locally to output a static site. I'm guessing that would disable the email/contact function (and other dynamic features) though.

I saw [*Decap CMS*](https://decapcms.org/) mentioned as another possibility but the editor seems too limited.

It looks like the other "Best Flat CMS" options are also not static sites.

That said, IMO, they're not the best solution for:

> I'm a novice with no expertise in website building or design.

<user hat on>

SSGs don't prioritize ease of use, necessarily, but simplicity and cost of hosting. If your only goal is to get a very simple website up and running, using a CMS + SSG + configuring hosting is kinda overkill, IMO. You might save $10/mo but end up spending hours longer to get it up and running.

Aside from Squarespace, there's also Wix, Weebly, Wordpress.com, and a bunch of other WYSIWYG page builders, many with free plans. Those are probably more appropriate for generic small-biz websites, not only because they are easier to use, but because it's a single-source solution. If something's wrong, if the site goes down or you don't know how to do something, there is one company to reach out for support, and it's their sole responsibility to make sure your website still runs.

If you use self-host a CMS and host it on a VM, use a separate SSG to publish your files to be hosted on yet another host... that's like 4-6 sources of potential failures, and nobody to support you through the whole journey. It can cause a lot of frustration later on if you run into bugs you can't easily solve on your own.

A large part of my job is supporting customers in similar circumstances, and the lines between "I coded something wrong" and "there's a bug in the CMS" and "there's a bug with the SSG software" and "there's a bug in my webhost config" and "there's a network/caching issue with the webhost themselves" can be very blurry. If you don't have at least some basic networking and frontend experience, this sort of setup adds quite a bit of fragility and complexity over your typical $10/mo vendor-supported small-biz site. That's not a good value for most people. Even tiny nonprofits can afford $10-$20/mo for "normal" web hosting that they don't have to babysit constantly.

</user hat>

-----------

<dev hat on>

Where SSGs and Jamstacks ARE valuable are for small to medium teams who want a clearer separation between content, data storage, and presentation -- usually because different individuals work on different parts, so you don't get marketers accidentally composing invalid markup or breaking JS, and you don't get dev code pushes interfering with the editorial process.

Content: Whether there's a WYSIWYG GUI editor or Markdown files, the point of this part is to make it so that anyone can edit articles, add images, etc. without extensive training.

Data storage: This can be flat files, a real database, NoSQL, whatever. It can be self-hosted or vendor-hosted.

Presentation: You can use a built-in template, extend one, or fetch your content via API and write a bespoke frontend from scratch.

Overall, the basic idea is simply a separation of concerns. Different software/teams/individuals can focus on their areas of expertise without accidentally stepping on someone else's toes.

That's hard to do in a "traditional" full-stack CMS setup like Wordpress or Drupal, which has hooks into all three parts, and usually deploys them together. That's why companies like Pantheon, WPEngine, and Acquia had to create their own virtualized hosting and deployment pipelines (like Pantheon's: https://docs.pantheon.io/pantheon-workflow), which give you a cleaner separation of concerns by imposing an out-of-band system that lives outside the software itself.

The headless CMSes (or even Wordpress & Drupal, configured appropriately, like using Wordpress Advanced Custom Forms or the Drupal REST API) + a SSG, on the other hand, do this natively.

The content editors get a nice interface they can use to add posts and media. They don't have to worry about breaking any code by accident, or configuring schema and plugins, or invalid compositions of content. It's a "walled garden" (lined notebook? not sure the best analogy here, lol) of the good kind: it lets them do their jobs without extraneous concerns/risks.

The data storage is abstracted away, and in the case of vendor-supported solutions, don't require any maintenance or backend staff to support. Even if you self-host, usually this layer usually requires minimal time, maybe just the occasional software update to the latest version (assuming nothing breaks).

The devs can now focus on frontend code, whether it's a webpage or an app or whatever the next-gen presentation interface is. They can rewrite the entire frontend time and time again without interfering with the editors. If they want to do it in Next.js now and rewrite the whole thing in HTMX tomorrow, they have that option, and editors never have to care or stop working. It's all just fetched via API.

</dev hat>