Einfachere Software. Bereit für KI-Agenten.

Tiefere Entwicklungskosten, weil es weniger Architektur zu bauen und synchron zu halten gibt. Tiefere Betriebskosten, weil ein Server viele nutzungsabhängig verrechnete Cloud-Dienste ersetzt. Schnellere Änderungen, weil Logik und Zustand an einem Ort liegen. Und eine planbare Performance, weil der Server bestimmt, wie viel er sendet.

Serverseitig gerendertes HTML ist, wie das Web angefangen hat. Neu ist, dass Updates über eine einzige SSE-Verbindung gestreamt werden: Die Seite fühlt sich live an, ohne dass Ihr Anwendungszustand in den Browser wandert.

Wir haben es zweimal gemessen, auf einem Mittelklasse-Handy über langsames 4G. Unsere Version derselben Chat-App war 8.3-mal früher interaktiv als das Next.js-Original, und auf unserem Kanban-Board ist eine verschobene Karte nach 253 ms vom Server bestätigt, wo PLANKA, gebaut mit React, 712 ms braucht.

Mit einem einzigen Writer ist die Performance fast nie das Problem. Alle Schreibzugriffe laufen nacheinander über eine Verbindung, warten also nie auf die Locks der anderen, und Lesezugriffe laufen daneben, ohne zu warten. Die Datenbank ist eine Datei neben der Anwendung, eine Abfrage kostet also keinen Netzwerk-Roundtrip. Was ein einziger Writer ausschliesst, sind viele Prozesse, die gleichzeitig schreiben, und die Architektur ist so gebaut, dass sie das nicht braucht. Der Writer unseres Kanban-Boards schafft rund 13’800 Verschiebungen pro Sekunde, wenn 200 Leute gleichzeitig Karten verschieben.

systemd startet einen abgestürzten Prozess innert Sekunden neu. Litestream kopiert jede Änderung etwa eine Sekunde später in einen Object Storage in der Schweiz, und ein täglicher Test-Restore prüft, dass die Kopie funktioniert. Fällt der Server selbst aus, stellt ein neuer die Daten beim Start wieder her. So läuft unser SaaS Libretto. Bis der neue Server läuft, ist die App offline. Für die meisten Geschäftsanwendungen ist das ein fairer Preis dafür, keinen Cluster zu betreiben; wenn nicht für Ihre, sagen wir Ihnen das, bevor wir anfangen.

Für die meisten Geschäftsanwendungen ist es der falsche Standard. Offline-First heisst optimistische Updates: Der Browser zeigt ein Ergebnis, bevor der Server es angenommen hat, und muss es zurücknehmen, wenn der Server ablehnt. Damit wandert die Konfliktbehandlung in jeden Client. Wir lassen den Server entscheiden und zeigen ehrlich, was er bestätigt hat. Wo echtes Offline-Arbeiten unverzichtbar ist, ist eine native App das bessere Werkzeug.

Go, SQLite und systemd sind langweilig, offen und weit verbreitet. Der Code gehört Ihnen, und wer Go kann, kann ihn übernehmen.

Nur wenn Sie es so entscheiden. Unsere MCP-Server lesen standardmässig nur. Schreib-Tools gibt es nur im Schreibmodus, und jede Änderung wird als Vorschau gezeigt, bis jemand sie bestätigt.

In einer ausufernden Architektur schon. In einer kleinen Codebasis mit einem Binary und einer Datenbank kann ein Reviewer noch jede Änderung lesen, und genau darum geht es.