Keeping what you write in your own hands — a small publishing tool

Part 1 of 5 — series: Building a publishing tool, and shipping it. Each part stands on its own; to follow the whole thing, see the series index. This part is the groundwork — what I wanted, and how the pieces fit. The individual design decisions come in later parts.

Where does what you write end up?

Most of the places we write are on someone else’s platform. They’re easy to be read on, but the post’s address (its URL), its look, and your connection to readers all live by that platform’s rules. If the service changes course or shuts down, your writing goes with it.

That isn’t bad in itself. But for the writing I want to keep around a long time, I wanted it a little more on my own side. That’s what got me started on a small publishing tool, crofty.

In this series, I’m writing down what I thought about — and tripped over — while building crofty and getting it out the door. This first part lays the groundwork: what I was after, and how the whole thing flows.

What I was after

In a word: to own my content while still publishing it. Concretely, four things:

Put plainly: I wanted what I write to outlive the tool that makes it.

Why not just an existing tool

Here’s the honest question. Tools for building static sites (SSGs) are already excellent — Hugo, for one, is fast and stable. In fact, crofty uses Hugo under the hood. So why build something else?

Because publishing doesn’t end at writing. Once you actually do it, small chores gather around the writing:

I wanted these as thin, one-command-at-a-time steps, rather than a different ritual each time. crofty isn’t a replacement for Hugo; it’s a small tool laid thinly on top. The base stays plain Hugo, so you can drop crofty at any moment and treat it as an ordinary Hugo project. That “always able to take it back into your own hands” feeling mattered from the start.

(How to guarantee that the posts stay yours even when the tool changes is a whole post on its own, so I’ll leave it to the next part.)

How it flows

The actual flow is simple. Write Markdown, build, deliver. Pretty much that.

From writing Markdown, to crofty build producing a static site (dist), to crofty deploy serving it from the edge, to a reader's browser.
Write → build → deliver: a single straight path.

The commands, lined up by role, come to just this:

Command Role
crofty init set up a place to write
crofty build turn Markdown into a static site (dist)
crofty validate check that posts are well-formed (front matter, etc.)
crofty doctor check the output will open correctly where it’s served
crofty deploy deliver to the edge (Cloudflare Pages)
crofty theme adjust the look

No new runtime or database. What you write becomes dist, a pile of static files, and you just serve those. So it’s fast, and even if you revisit the machinery later, the posts themselves stay untouched.

Everything is a plain command typed at the terminal. A person can type them by hand; and because the steps are clear, it’s also easy to call from automation.

This very blog is built with it

For a bit of credibility: the blog you’re reading is itself built with crofty.

So it keeps its speed while still using figures, tables, and code as normal. I build it and use it day to day, fixing the rough spots as I hit them. That’s how it took shape.

What’s next

From here, the later parts dig into the individual decisions, one topic each:

None of these are unique to crofty; they’re the road you walk whenever you make a small tool and give it away. If you also feel like keeping what you write in your own hands, I hope some corner of this helps.


Next: Contract the output