Static sites are the best way to publish most personal writing. They’re fast, cheap to host, close to unhackable and easy to move. The trouble is that the usual way to make one assumes you’re comfortable in a terminal, and plenty of good writers aren’t. Nor should they have to be.

This post explains what a static site generator actually does, where the friction comes from, and the realistic ways to get the result without the toolchain.

What a static site generator does

A static site generator (SSG) is a program that turns your writing into a finished website before anyone visits it.

You give it three things:

  1. Content, usually posts written as Markdown files, each with a little metadata at the top: title, date, tags.
  2. Templates, which describe how a post page, the home page and an archive page should look.
  3. Configuration: the site’s name, its address, how URLs should be structured.

It gives you back a folder of plain HTML, CSS and images. It also generates the pieces a blog needs around the posts: index pages, tag archives, an RSS feed, a sitemap.

You upload that folder to any web server or static host, and you’re done. Nothing runs when a reader arrives. There’s no database and no admin panel. That’s why static sites are so fast and so hard to break.

Why the toolchain puts people off

The concept is simple. The tooling is not, at least for anyone who hasn’t spent time as a developer. Each popular generator brings its own ecosystem.

Hugo is written in Go and ships as a single executable, which is about as easy as it gets. But themes are commonly installed as Git submodules or Hugo Modules, and Hugo’s documentation lists both Git and Go as prerequisites for modules. If your theme uses Sass, you’ll need the extended edition.

Jekyll is a Ruby gem. Its installation guide asks for Ruby 2.7 or newer with development headers, RubyGems, and the GCC and Make build tools. Getting a working Ruby environment on a Mac is a rite of passage many people would happily skip.

Eleventy needs Node.js 18 or newer and is installed with npm. Astro needs Node.js 22.12 or newer, and its documentation specifically notes that odd-numbered releases such as v23 aren’t supported.

None of that is unreasonable for a developer. But look at what a non-developer has to learn before writing a single post:

And then, six months later, updating something and finding the theme no longer builds. That’s the real cost. It’s not the first afternoon; it’s the maintenance tax on something that was meant to be low-maintenance.

The options that avoid the terminal

There are three broad approaches. Each moves the complexity somewhere else rather than removing it, so it’s worth knowing where it goes.

A CMS front-end on top of an SSG

Git-based content management systems give you a web editor for a site that’s still built by Hugo, Jekyll, Eleventy or similar. Two open-source examples:

Once set up, these are pleasant for writing. The catch is “once set up”. Someone still has to create the repository, choose and configure the generator, configure the CMS and connect a host that builds on every commit. They’re excellent when a developer sets up a site for a writer. They don’t help much if you’re both.

A hosted builder

Services like CloudCannon take on the whole pipeline: they connect to your repository, build your site, host it, and give you a visual editor. It’s a serious product aimed at agencies and teams, and it’s priced accordingly. At the time of writing its Standard plan is $55 a month, or $49 a month billed annually. That’s good value for a business, and a lot for a personal blog.

A native app

The third approach puts the generator inside an application on your own computer. You write in the app, it builds the site locally, and it uploads the result.

Publii is the established example: a free, open-source desktop app for Windows, macOS and Linux. It includes themes, works offline, and publishes to an SFTP server, Amazon S3, Netlify or GitHub Pages, among others. If you want a desktop tool on any operating system, it’s well worth a look.

The appeal of this model is that the complexity really does disappear rather than moving to a server you have to operate. There’s no runtime to install, no repository to manage and nothing to build in the cloud. The output is a normal static site you can host anywhere.

The limits are real too. You get the themes and features the app provides, not the unlimited flexibility of writing your own templates. You can’t install a plugin to add something the app doesn’t do. And your writing lives in the app’s own storage, so it matters how open that app’s output is.

Where Selfish fits

Selfish takes the native-app approach on Apple devices. It’s a single app for iPhone, iPad and Mac (running iOS 26, iPadOS 26 or macOS 26), on the App Store as a one-time purchase, at a £3.99 introductory price, rising to £9.99 in December.

You write in a plain-text composer with a small formatting toolbar, or type a small subset of Markdown directly. The preview matches the published page exactly. Selfish generates a complete static site, with an RSS feed, a JSON feed, a sitemap and category and tag archives. It then publishes to your own server over SFTP, to S3-compatible storage, or to Netlify, Cloudflare Pages or GitHub Pages. Four themes are free; three more are optional one-time purchases. The themes page shows them all.

It’s fair to be clear about what it doesn’t do. There’s no custom theme editor (it’s being considered, not built), no plugins, no comments and no email newsletters. It’s Apple-only. And if you enjoy crafting templates in Hugo, you’ll find a curated set of themes more limiting than a blank canvas. For that, Hugo is the better tool, and we’d say so.

But if what you want is to write a post on your phone and have it appear as plain HTML on a server you control, without ever opening a terminal, that’s the job Selfish is built for. The user guide shows how it works.