Why we write a journal

This is where Elchi Studios writes down what it builds and what it decides, and why. Not a news feed and not a list of features. When something changes that a client, a developer or anybody else relying on us would notice, it gets written up here in full: what changed, the reason, what it costs, and what is still missing.

Why write it down at all

A website tells you what a company sells. It rarely tells you how the company works, and that is what you are actually trusting when you hand over your website, your sign-in or your mail. A changelog comes closer, but a changelog says what changed and almost never why. The why is the useful part. It is also the part that gets forgotten first, including by us.

So every decision that matters goes here, with its reasoning, while the reasoning is still fresh. If we get something wrong, the post that explains the mistake stays next to the post that explains the fix.

What goes in, and what does not

A post describes something you can use or notice today. Plans, "coming soon" and features that exist on a slide do not get a post. When something is only half done, the post says which half.

Every post is signed by the person who wrote it, with their role, because a statement from a company is only worth something if somebody stands behind it. Claims that can be checked link to their source: the RFC, the vendor's documentation, the measurement. Numbers replace adjectives wherever there is a number to give.

The journal is in English. EAuth, our developer documentation and most of the people building on them work in English, and one language means every post reaches everybody at once. The rest of elchi.dev stays German first, because that is the language of the businesses in Zug we build websites for.

A post does not change behind your back

The address of a published post and the day it first appeared are permanent. That is not a promise, it is a rule in the database: an attempt to change either is refused, whoever makes it. If a post needs correcting later, the correction is made in the open and the post shows the day it was updated next to the day it appeared. We would rather correct than delete.

Readable without running anything

More and more people find things through search engines and language models rather than by browsing, and both read pages the way a very patient person with no patience for JavaScript would. So the journal is built as plain files:

• every post is complete HTML, with nothing loaded afterwards to show the text;
• every post is also available as Markdown at its own address with .md added, with the author and the dates in front matter and the sources listed under the text;
• there is an Atom feed for anybody who prefers a reader;
• structured data tells search engines who wrote a post, when, and what it cites;
• the site's llms.txt lists the newest twenty posts, each with the address of its Markdown.

Pictures go through the same pipeline as on every site we build: AVIF and WebP in six widths from 320 to 2560 pixels, served from our asset host, each with a description for people who cannot see it. A picture without a description is refused.

How it is made

Posts are written in the same dashboard we use for everything else on elchi.dev, or sent to its API with a key that belongs to one author. The text is Markdown, checked before it is saved: one title, no raw HTML, pictures only from our own media library. A second check points out phrases that make a text sound like a brochure. It warns and does not refuse, because the person writing decides. One rule is not left to anybody's judgement: the database refuses the em dash and the en dash in a title, a summary or a body.

Publishing does not change the site by itself. elchi.dev is plain files, so a post appears with the next build of the site. That build fetches every published text from the API, and if the API does not answer, it stops rather than ship a site without the new post. The cost is a step between publishing and a post being online. The gain is that every page a reader sees was built and checked as a whole.

The first posts cover the release of 3 October 2026: EAuth moving to a domain of its own, the limits on every sign-in, and a handful of fixes that each taught us something.