When we started building our own apps, we made a choice that sounds almost contrarian in 2026: no cloud backend by default. Every app we make is local-first — your data lives on your device, and the network is an enhancement, not a requirement.
How that local-first app actually reaches you varies, and it’s worth being precise about it. Echo runs in the browser as an installable Progressive Web App (PWA). Flow, Notes, and Pulse are proper native desktop apps, built with Tauri. Different wrappers, same foundation — and that foundation is the interesting part.
Your data should be yours
The simplest privacy model is the one where the data never leaves the device. Pulse processes project knowledge with local inference; Flow keeps every board in a local database with an explicit export; Notes stores everything on disk and nowhere else. There’s no server quietly holding your information, which means there’s nothing to breach, nothing to leak in someone else’s incident report, and nothing to hold hostage behind a renewal notice. For tools people use for work — project plans, client notes, half-formed ideas — “we literally never see it” is a stronger promise than any privacy policy.
Local-first is just better UX
An app that assumes a perfect connection feels broken the moment you’re on a train, in a basement meeting room, or on hotel wifi that’s technically connected and practically useless. Local-first flips the default. The app is always fast because it’s always reading from local storage, and the network becomes something that adds — sync, updates, optional cloud features — rather than something the whole experience waits on. Whether it’s Echo in a browser tab or Flow in its own window, it opens instantly and never shows you a spinner where a thought used to be.
One foundation, two delivery models
This is the part we get asked about most, so here’s the honest breakdown.
Echo is a PWA. It’s a focused, lightweight tool — timeline mapping for PowerPoint — and it lives in the browser. A service worker caches the app so it works offline, and a web app manifest lets you install it to your dock or home screen. For something you reach for occasionally and want zero-install access to, the web is the perfect delivery vehicle.
Flow, Notes, and Pulse are native desktop apps. They’re built with Tauri, which wraps a web UI in a genuinely native shell — so they’re real OS applications, not browser tabs. That buys things a browser sandbox can’t do cleanly: a global quick-capture shortcut and system-tray presence (Flow, Notes), a fast local SQLite database, and — in Pulse’s case — on-device AI inference that would be impractical to run in a tab. They’re distributed as signed installers and update themselves in place.
The throughline is that the delivery model follows the tool, not the other way around. A quick utility leans web; a daily-driver, desktop-class tool leans native. Both keep your data local.
The economics change in your favour
No servers means no per-user infrastructure cost, and that quietly rewrites the business model. When every active user isn’t a line item on a cloud bill, you can ship a genuinely useful free tier without bleeding money, and charge for the things that actually warrant it — a licence, a pro feature, optional sync. It also means the app keeps working if the company behind it goes quiet, which is exactly the kind of resilience people wish more of their tools had.
The trade-offs are real
This isn’t a free lunch, and pretending otherwise is how teams get burned. Sync across devices gets genuinely hard the moment two devices can edit the same data offline — you’re now in conflict-resolution territory, and naive “last write wins” silently eats people’s work. Backups become the user’s concern unless you design for them deliberately. The native apps add their own overhead: code-signing and notarization on macOS and Windows, plus a real release pipeline for the installers. And “local-first” only works if you actually test it offline, on a throttled connection and a cold cache, not just on your fibre line at the desk.
How we handle the hard parts
We treat cloud sync as a first-class feature to add on purpose, not a default to lean on — with real conflict handling, not a hope and a prayer. Data lives in a single local store with one-click export and import, so a backup is never more than a moment away. The desktop apps ship signed, with a built-in updater so fixes land without a trip to a download page; Echo updates itself the moment its service worker refreshes. And licensing, when there is any, validates online but caches a generous grace window, so a paying user on a plane is never locked out of the thing they paid for.
When not to do this
Local-first is the right foundation for tools where the data is personal and the work is individual — notes, boards, knowledge, planning, a slide timeline. It’s the wrong default for inherently collaborative, real-time products where a shared server is the point. The trick is to be honest about which one you’re building — and then to pick the lightest delivery model that does the job, whether that’s a PWA or a native app. For most of the software we make, local-first is the better place to start, and you can always add the cloud later, deliberately, as a feature rather than a crutch.