An example of our generality in action
We recently updated the Megargy website to explain our three principles: Simplicity, Clarity and Generality. Here is an example of how we recognise generality in software we already use internally—and why recognising an opportunity does not necessarily mean we have found a new commercial service.
We built the same thing three times
Babylon, Megargy and Fietsers (personal website) have quite distinctive homepages and serve different audiences, but all three use Hugo to publish articles. Each has an article listing, individual article pages, dates and navigation. Fietsers includes featured images in its listings, but otherwise the commonality is striking.
We had essentially solved the same problem three times. Could we generalise it?
Two sketches reveal how little needs to vary
Our first sketch shows an article listing. The red annotations identify the elements that need to be configurable to achieve generality.
Article listing: a standard structure with a few configurable details.
The logo links to the customer’s main website; the menu and footer are simply links. The introduction, company name and date format can vary, while a newsletter invitation or featured images could be optional.
The individual article is simpler still.
Individual article: a clear reading layout, without unnecessary design options.
An article needs a title, author, date and content, including room for tables, images and references. A comfortable reading width and clean margins matter more than a page builder.
Two standard layouts, great defaults and a little optional customisation appear to be enough to achieve generality. (Of course, we realise fonts, colours and so on need to be configurable as well, but that is fairly obvious.)
The technical catch
Our existing articles live under /articles/ on their respective websites. An independent publishing service cannot assume that a customer’s website uses Hugo—or that we can modify its deployment.
We would instead use a customer-controlled subdomain, such as articles.example.com, linked to the main website. That requires some initial setup. Moving our existing articles would also require redirects to preserve links and care with search indexing.
Test it on our own website
Our next step is to generalise the implementation and use it on Megargy itself. That would improve our publishing process and test the solution with real articles. We could then consider using the same approach on Babylon and Fietsers.
We are provisionally calling the possible offering Megargy Hosted Articles Service. We are not yet sure that it needs to become a commercial service.
Who might want it?
Consider a less technical founder who hires a consultant to build a website. The consultant uses AI to create a simple website, perhaps with React. Such a website can be delivered and hosted without a content management system and with very little ongoing cost.
But what happens when the founder discovers content marketing and wants to publish articles regularly?
Without a content management system, the founder may need to return to the consultant for each change. With our proposed service, the consultant would configure the articles subdomain once. After that, the founder could write an article—perhaps with AI—submit the Markdown and have it published without involving the consultant.
RSS connects publishing to newsletters
Some AI-built websites do not include an RSS feed simply because nobody requested one. A technically confident founder could ask AI to add article publishing and keep an RSS feed updated. That may be a perfectly good alternative to our proposed service.
But asking AI to build newsletter distribution is a different matter. It would also need an email provider, subscriber management, consent, unsubscribes, bounce handling and complaints. Why rebuild all that when established RSS-to-email services, including Megargy Newsletter Service, already exist at modest prices?
Our proposed articles service would provide RSS as standard, leaving customers free to choose a newsletter provider.
Generality is not proof of demand
The functionality looks straightforward to generalise, and the founder’s situation offers a plausible use case. Yet technically confident customers may prefer to maintain their own article publishing with AI. We do not know how much demand there would be for a separate service.
That does not undermine the exercise. Generalising what we already use internally improves our own systems. If a market emerges, we can offer the service to others. If not, the work still has value.
Generality means recognising what can be reused, improving it through actual use, and only then deciding whether it should become a commercial service.