On this site, correcting a title on the live page writes a commit. Not a row in a database: a commit, with a date and a diff. The latest one is called content: édition inline (1 champ), and it removes a sentence from a milestone on the « about » page.
Many clients touch their site with their fingertips, afraid of breaking everything. Obscure fields, a preview that lies. I do not think they are wrong: on plenty of sites the fear is well founded, and one badly filled field is enough to bring a page down.
Editing on the site, not beside it
With Sveltia, you edit the site from the site. Logged in, you switch editing on, you click a title, you correct it, you publish: the build starts again, it is live. What you see while editing is what will be published, because it is the same page. No separate preview that diverges, no parallel interface to learn.
The first time, you look for the catch. There is none, but there is a trade-off: this editing only works on texts the developer has declared editable. A text forgotten in a template stays out of reach until someone has wired it up.
Why a commit rather than a database row
Every change is a versioned text file, so everything can be found again, and going back needs no backup because the backup is the mechanism itself. The content is Markdown and JSON, readable in ten years, exportable in a second since it is already exported.
Two people editing the same text at the same time, on a database, produce a silent overwrite: the last write wins, the first one disappears without a trace. Here, publishing reads the branch reference again before writing, and starts over if it has moved in the meantime. That is git’s normal behaviour, picked up for free.
One single truth, and one single source of error
The CMS and the pages read the same files. No synchronisation coming loose.
In exchange, there is a mirror to keep. A field added to the src/content.config.ts schema must exist in public/admin/config.yml, otherwise it becomes invisible from the admin, and the site works perfectly while hiding that part of the content can no longer be edited. It is the kind of failure that wakes nobody up.
I have found nothing better than to write it out in full in the repository’s rules file.
What the fear of breaking costs
A site nobody dares change freezes. Prices age, references go out of date, a page describes a service that no longer exists. The cost of an intimidating back office lies in those corrections that never get made. Nobody decides to let their site lie. It lies because correcting it meant calling someone, and that could wait.



