Operators ask for “QuickBooks Desktop, but modern.” A progressive web app (PWA) can get surprisingly close on day-to-day ledger work after the app has loaded at least once: the UI shell can cache, and a local database can keep serving reads and writes without hitting a remote general ledger on every click. What a PWA cannot honestly promise is everything offline forever. Some functions are inherently networked: first-time sign-in, email verification, downloading updates, live bank aggregation, and payment processing.
Three layers people confuse
- App shell offline: the JavaScript and assets needed to render screens.
- Data offline:your ledger file stored locally (for example in the browser's private storage).
- Integrations offline: almost never—bank feeds and card processors are network services.
Why local data still matters if you are not “100% offline”
The win is not pretending the internet does not exist. The win is removing the hosted GL from the critical path for register scrolling, journal posting, and most reporting. That is the same architectural advantage we discuss in why local ledgers feel faster and field operations time windows.
Backup discipline does not go away
Local-first means responsibility shifts: you should export on a rhythm that matches risk (weekly for active books, more often during migrations). Browsers can be cleared, devices can be lost, and OS updates can surprise users. A portable database file is the blunt mitigation. Read SQLite portability and evidence you can hold.
Buying questions to ask any vendor claiming offline
- Which screens work without connectivity after first load?
- What happens to in-flight posts if the tab crashes mid-save?
- How do I export the full database—not just reports?
- What is the recovery story if I lose the device?
Privbooks is candid: web apps have browser constraints, and honest operators document them. If the trade works for you, start on Starter and prove the backup path before you rely on it.