Why Bookleaf works with the internet unplugged

Most library software describes itself as offline-capable, and means something specific by it: the app keeps working for a while when the connection drops, queues up what you did, and syncs when it comes back.

That is a reasonable design. It is also not what Bookleaf does, and the difference matters more than the phrasing suggests.

Bookleaf has no online mode to fall back from. Your catalog is a file on the librarian’s computer. Patron phones talk to that computer directly over your Wi-Fi. There is no account server, no sync queue, and no cloud copy — so there is nothing to be offline from.

Why we built it this way

The schools this product was made for do not have intermittent internet. They have internet that is absent for a week after a storm, or a connection shared with three hundred students that is effectively unusable between 8am and 4pm, or no connection at all.

“Syncs when it comes back” quietly assumes it comes back today. When it does not, a sync-based system degrades in a specific and unpleasant way: the librarian keeps working, a backlog accumulates invisibly, and the eventual reconciliation surfaces conflicts from a week of transactions nobody can now remember.

The library in the meantime has been running on paper — which is where it started.

What the constraint bought us

Committing to it fully turned out to simplify things rather than complicate them.

There is no sync layer. Sync is where distributed systems get hard: conflict resolution, ordering, partial failure. Bookleaf has one database with one writer. A whole category of bugs never gets written.

Privacy is structural rather than promised. We cannot look at your students’ borrowing history, because we never receive it. That is not a policy we could quietly amend later — there is no code that sends it anywhere.

The economics change. No servers to run means no recurring cost on our side, which is why the licence can be a one-time ₱1,499 software license instead of a subscription. A cloud product must charge annually because it pays for hosting annually. We do not, so we do not.

The library outlives us. If Bookleaf stops being developed tomorrow, every installation keeps working. Nothing phones home, so nothing can be switched off.

What it costs

Being straight about the trade, because it is a real one.

No access from outside the building. Students cannot check the catalog from home. This is the single most common request we get, and it is the one thing the architecture genuinely cannot give without becoming a different product.

No automatic email or SMS notices. Overdue reminders appear in the app and on the librarian’s dashboard, not in a student’s inbox. Sending mail requires exactly the dependency we removed.

Backups are yours to take. Nobody is quietly backing your data up for you. This is the risk that a cloud service genuinely handles better, which is why our backups documentation is more insistent than a documentation page would normally be.

For a library with reliable internet and a permanent budget, those costs may well outweigh the benefits, and a hosted system is the better choice. We wrote that comparison rather than pretending the question does not arise.

But for a school library where the connection is unreliable and the budget is uncertain, the trade is not close. A library system that requires the internet is a library system that stops working, on exactly the days when the reading room is full.