Internet flâneur • Pagecord foundling


The plague of offering a free website/blog platform is the spammers. They’re relentless. I’ve largely automated spam detection now, but it’s eye-rolling to see them keep trying, day-in, day-out. Here’s a prime example.

Try harder, bots.

The Pagecord Principles

I've been updating the Pagecord home page today with a new headline, refreshed hero text, and a new section called The Pagecord Principles.

The idea is to encapsulate why Pagecord exists and what it stands for. I'm hoping this resonates with bloggers visiting for the first time, encouraging them to sign up to Pagecord rather than (or as well as) one of the many, many alternatives.

It's not a political standpoint or a side-swipe at the competition, just a set of founding principles that guide the development and evolution of the product.

I think it brings more purpose. What do you think?


Write more, manage less

Pagecord reduces the ceremony around blogging. Publish what you like, when you like, from wherever you like. A single photograph, a quick thought, a full-on essay. Everything looks great. Don't let overthinking hold you back – write and publish whenever you feel the urge.

Use your favourite writing tool

Pagecord lets you use the writing tools you already love. Use the fantastic web editor, post by sending an email, publish from Obsidian, or publish from the terminal using the CLI or API.

Own your home on the web

Pagecord gives writers a long-term home on the web. Bring your own domain name, create your own design. Export your entire site, including images, any time in HTML or Markdown format. No lock-in. Easy to leave, but worth staying for.

Embrace boring web standards

Pagecord embraces the original dream of the World Wide Web. Fast, lean, semantic HTML that looks great on every device. Tiny JavaScript sprinkles, evergreen permalinks, RSS, and email. No bloat, no adverts. Built for the long haul using tried and trusted tech.

Allow people to follow, calmly

Reading a Pagecord blog should be as effortless as writing on one. Every Pagecord blog comes with RSS support. Premium lets readers subscribe to weekly email digests, or individual posts by email. Readers can also reply privately to posts using email.

Complete, not complicated

Pagecord includes posts, pages, themes, analytics, email subscribers, custom domains, and full export. Everything you could reasonably need, for a most reasonable price.

I love that Pagecord is open source but it's a double-edged sword because I see features being copied all the time. I don't read competitor blogs, but sometimes I come across things. I guess it's not a big deal given the arrival of coding LLMs – anyone can build anything at any time, right? – plus I've certainly been inspired by other products. Yet, people can literally see my work in progress and copy the product, and there's FA I can do about it. I have no IP moat. 

It doesn't bother me too much (just a little!) and it just means I have to make everything that is Pagecord but isn't the product better than anyone else can match. Customer support, community, brand, trust, performance. That sort of thing. Anything else? How do you think it's going and what could be improved?

Biggest IPO of all time and Musk’s speech is a 5 sentence sci-fi B movie word salad that literally makes no sense. That’s all you got?

I always think about this. There are always problems on earth. There’s always things that we wish to be better, that we want to solve here on Earth, and we should solve them. But there also have to be things that get you excited about the future - that make you glad to wake up in the morning, because you can’t wait to see what happens next. And that’s the future SpaceX wants to bring to you.

AI-sphyxiation

AI-sphyxiation /ˌeɪ aɪ sfɪksiˈeɪʃən/ (AY-eye sfik-see-AY-shən)
noun

The gradual suffocation of otherwise useful products by unwanted and unwarranted AI features.

“Google Photos has been completely AI-sphyxiated.”

Etymology: A portmanteau of AI and asphyxiation; literally, “suffocation by AI.”

See also: enshittification, slopification

Pagecord CLI

I’ve published a small Pagecord command line app (CLI) for people who want to write on their local machine in Markdown (or HTML) and publish those files to Pagecord. If you use Obsidian, you should use the dedicated plugin, but if you use something else then the CLI app might be able to help.

The app is written in Ruby (❤️), and you install it from RubyGems:

gem install pagecord-cli

Once installed, you can log in using the login command and passing your blog subdomain:

pagecord login blog-subdomain

This will ask for your API key, which will be used to authenticate you.

Once you're logged in, you can save posts to your blog as draft or published using the draft and publish commands:

# subdomain is only required if you're logged into two or more blogs
pagecord draft post.md [subdomain]
pagecord publish post.md [subdomain]

If you want to move a published post back to draft, use the draft command.

Images

Images are supported as with the Obsidian plugin. Just reference the local file in your Markdown and it will be uploaded to Pagecord.

After syncing a file (draft or published), you'll notice some frontmatter entries appear such as pagecord_token, pagecord_blog_fingerprint, and pagecord_attachments – these are required by the app to identify the blog post and attachments in Pagecord, so please don't edit them.

Options

Frontmatter in your Markdown file is supported as per the Obsidian plugin, but if you prefer you can use CLI options to configure the post.

Note: The CLI app and Obsidian plugin use the same Pagecord frontmatter, so you can move between them. A post first published from the CLI can later be edited and synced from Obsidian, and a note first published from Obsidian can later be updated from the CLI.

Setting the title (or no title)

# by default the title is set to be the same as the file name
--title "Custom title"
--title ""

Changing the post slug

--slug my-new-post-slug

Changing the publication time

--published-at 2026-06-11

Adding tags

--tags ruby,cli

Add canonical URL

--canonical-url https://example.com/original

Making the post hidden

--hidden

Changing the post locale

--locale en

The CLI app covers the main workflows. If you want to delete a post, you'll need to head into the Pagecord UI.

Hopefully this app opens up options for people who want to write locally in other editors like iA Writer, Vim or Emacs, or do some automation, but who don't want to fiddle with the Pagecord API itself.

Composing your blog posts locally on your own device is a great way to use Pagecord. You can export your data from Pagecord at any time of course, but writing locally means you own all your content from the outset. Your posts are just files that you can back up, store on Dropbox, whatever you like!

This is how I write most blog posts now, and I've published this one using the CLI app itself.

I’ve managed to stay away from macOS 26 (Tahoe) and it looks like macOS 27 (Golden Gate) might be safe to upgrade to. Apple appears to have listened to the Liquid Glass horror stories and fixed many (most?) of them.

Liquid Glass remains, of course (Apple UIs tend to last several generations), but it seems far more refined and less transparent which is as close to an admission of failure you’ll get from Apple I think. Either way, it seems almost pleasant to my eyes now. 

There’s no chance of me installing a developer or public beta, but come 27.1 I’ll probably give it a go. Assuming it supports a five year old M1 MacBook Pro that is. 

Slow-cooking features

I first thought about the next chunky Pagecord feature 148 days ago, according to the Fizzy card I created (I use Fizzy to track all my Pagecord work). I put up the first PR 32 days after that, and I got it production ready today, 4 months later. 

The feature didn't take 5 months of me grinding at the keyboard every day. Far from it. In the agentic coding era it has probably taken only a few hours of prompting and LLM munching over that time. At most, a couple of day's work in total.

What's interesting to me about this isn't the flex of building a feature quickly without hand-cranking much/any code (that's still fascinating, for sure), but rather that it's still worth taking your time to let a feature sit and evolve a little before shoving it out the door. Not only will this help you find a few more bugs and edge cases, but you'll have more time to think about the implementation and whether you truly need it – could it be done more simply, is the additional complexity worth the cost, is now the right time, and what's the opportunity cost of not doing it? Time might change your mind.

You can put some things out there without much consideration or hesitation, but for the chunkier changes, my advice would be to live with it for a while. Let it sit and simmer, stirring only occasionally. Things often taste better when they've developed more flavour.

Junited 2026

A post on Sebastian’s blog introduced me to Junited, a fun celebration of blogging started by Robert Birming in 2024. In Robert’s words:

Junited is a little blog-loving adventure where the blogging community gets together to share posts they enjoy and discover new bloggers along the way

What a wonderful idea! I’ll be using this post to partake in it throughout June. I mean, I run an indie blogging platform myself so how could I not! 😊

Here's my list.

  1. Don't accept the premise
  2. Guidelines for Respectful Use of AI
  3. Why You Should Be A Techno-Skeptic
  4. Vivaldi (Chrome) ruining website colors
  5. What Basecamp Gets Right (And Others Don't)
  6. LLMs are eroding my software engineering career and I don't know what to do
  7. Writing a good essay is a lot like designing a room
  8. It’s hard to justify Tahoe icons
  9. AI demands more engineering discipline. Not less
  10. How to Earn a Billion Dollars
  11. Revised rules of engineering leadership
  12. How’s the writing going?
  13. The Weakest Link

Web Wanderings (May 2026)

I didn't come across a whole lot of interesting links this month. Or maybe I did and just forgot to make a note of them? That's probably more likely. Either way, here are a few things I discovered and liked.

  • As time passes, the larger our collection of digital stuff grows. Maybe whoami.wiki can help? "Your personal encyclopedia, written by agents". It's inevitable, but I'm not quite ready to hand it all over just yet.
  • I visited New Orleans with work in 2023. I loved it and I want to go back and see it properly. I should probably do this soon because In paleo-climate terms, New Orleans is gone; the question is how long it has.
  • P.T. Barnum wrote “The Art of Money Getting: The Golden Rules for Making Money” in 1880 at the age of 70. His advice is still on point today.
  • As a photographer, I am literally obsessed with the Grainydays YouTube channel.
  • Tapbots are launching Phoenix this summer, their Bluesky client. A tiny company worth supporting. They also make the wonderful Ivory for the Mastodon-inclined.
  • I enjoyed this Radio 4 Americast episode with Scott Galloway – The political fight for American men. An important topic (not just for Americans).
  • I thought I knew a lot about HTML but You don't know HTML Lists quite rightly makes me feel like an amateur. Fascinating.
  • 37signals launched Basecamp 5 and it looks brilliant. If I was still running a multi-employee business, I would use Basecamp, 100%. I'm just a one-man band, so I use the wonderful (and free!) Fizzy, which is also by 37signals. They're on 🔥 these days.
  • California seems to be way ahead with self-driving taxis, and upstart Zoox looks brilliant. The design is polarising, but I'm a fan – they seem very practical. I feel bad for taxi drivers because the writing's on the wall, yet I'd love to see these on the streets of Edinburgh one day.
  • Bubbles is like Hacker News but for independent blogs. I'm probably late to the party, but I love it – what a great idea.
  • Is AI profitable yet? 😬
  • If you’re feeling creative, make your own 8-page zine at home with the awesome Dirty Little Zine.
  • Thank you John Gruber for calling out the veritable scourge of incessant popovers, or “dickovers” as he has christened them.

If you visit a website you should ... see the website. See its content. Be able to read the article whose page you are attempting to visit. Showing a “subscribe to our newsletter” or “accept our fucking cookies” dickover to someone trying to read an article on the web makes no more sense than sending out an email newsletter that only contains a link to read the newsletter on a webpage. A webpage should show the webpage. An email should show the email. I should not have to explain this.

— John Gruber, What is a Dickover?

Uploaded image
People love 88x31 buttons in their blog footer, right? Having fun experimenting on a Friday afternoon...