Simpler software. Ready for AI agents.

Lower development costs, because there is less architecture to build and keep in sync. Lower running costs, because one server replaces a cloud of metered services. Faster changes, because logic and state live in one place. And predictable performance, because the server decides how much it sends.

Server-rendered HTML is how the web started. What's new is streaming updates over a single SSE connection, so the page feels real-time without shipping your application state to the browser.

We measured it twice on a mid-range phone over slow 4G. Our version of the same chat app became interactive 8.3 times sooner than the Next.js original, and on our Kanban board a dragged card is confirmed by the server after 253 ms, where PLANKA, built with React, needs 712 ms.

With a single writer, performance is almost never the issue. All writes go through one connection, one after the other, so they never wait on each other's locks, and reads run alongside them without waiting. The database is a file next to the application, so a query costs no network round trip. What a single writer rules out is many processes writing at once, and the architecture is built not to need that. The writer of our Kanban board handles about 13,800 moves a second with 200 people moving cards at once.

systemd restarts a crashed process within seconds. Litestream copies every change to object storage in Switzerland about a second later, and a daily test restore checks that the copy works. If the server itself fails, a new one restores the data as it starts. That is how our SaaS Libretto runs. Until the new server is up, the app is down. For most business apps that is a fair price for not running a cluster; if it isn't for yours, we'll tell you before we start.

For most business apps it's the wrong default. Offline-first means optimistic updates: the browser shows a result before the server has accepted it, and has to take it back when the server refuses. That moves conflict handling into every client. We keep the server in charge and show honestly what it has confirmed. Where real offline work is essential, a native app is the better tool.

Go, SQLite and systemd are boring, open and widely known. The code is yours, and any Go developer can take it over.

Only if you decide it is. Our MCP servers are read-only by default. Write tools only exist in write mode, and every write is shown as a preview until someone confirms it.

It will in a sprawling architecture. In a small codebase with one binary and one database, a reviewer can still read every change, and that is the point.