Local-first software (2019)

Relationship to Capitalism, SaaS, and Business Models

• Many see local-first as aligned with privacy, autonomy, and “software as infrastructure,” and as a reaction against subscription-driven “enshittification” and cloud lock‑in.
• Others argue the real problem is rent‑seeking and conflict‑of‑interest business models, not capitalism per se; some counter that this “corrupted capitalism” is just capitalism in practice.
• SaaS is framed as primarily a pricing/financialization model: predictable recurring revenue, higher valuations, easier approvals than large one‑time purchases, and psychological anchoring on low monthly prices.
• A recurring theme: there is no well‑established, equally attractive business model for local‑first. Proposed alternatives include: paid native apps with optional sync services; time‑limited update licenses; co‑ops with user governance; sysadmin‑as‑a‑service for self‑hosted boxes; and more radical ideas like UBI. Skepticism remains about their scalability.

Cloud vs Local: Trade‑offs and Governance

• Critiques of cloud/SaaS: lock‑in, surveillance, opaque business incentives, cloud as DRM, subscriptions for basic functionality, online dependencies that make products brittle (including games and appliances).
• Defenders note genuine benefits: multi‑device sync, collaboration, advanced features (e.g., data platforms), and the fact that many users want turnkey hosted services, not self‑administered systems.
• Some propose tackling cloud harms via contracts and standards (EOL guarantees, data portability, open/documented formats, audited access logs, escrow), rather than only technical decentralization. Others doubt enforceability and point out practical migration costs.

Technical & UX Challenges of Local‑First

• Core difficulty: the sync layer—conflict resolution, schema migration, multi‑device and sometimes P2P under NAT.
• CRDT-based approaches (Automerge, Yjs, Loro, Ditto, etc.) are praised for enabling offline collaboration but criticized for: complex semantics for real‑world conflicts, poor server‑side querying, and still‑necessary “manual merge” UIs.
• Opinions differ on maturity of third‑party sync engines (ElectricSQL, Ditto, InstantDB, Couch/Pouch, RxDB, etc.). Some report production success; others find docs and tooling immature.
• Several builders stress how much harder fully offline‑first is compared to “offline‑tolerant” apps, and how self‑hosting and P2P (TURN, NAT traversal) add operational burden.
• Web platform limits (same‑origin, service worker update model) are seen as a barrier to truly “download once, run forever” browser apps, pushing some toward desktop shells (Electron, Tauri).

AI, Local Compute, and Future Trajectory

• There is excitement about local LLMs and offline AI workspaces as a natural fit for local‑first ideals, but also concern that heavy AI workloads will further entrench cloud‑only services.
• Some expect hardware and models to catch up; others think generative AI will remain cloud‑centric for a long time, making many new applications structurally non‑local.

Practitioner Experiences and Patterns

• Many examples of local‑first or self‑host‑friendly tools (notes, finance, bookmarks, audiobooks, SCADA analytics) with optional sync via commodity storage (Dropbox, WebDAV, iCloud, etc.).
• A common pattern: free or cheap local client; optional paid sync or cloud convenience. Builders emphasize user control over data formats (plain files, SQLite) and the ability to “eject” to self‑hosted or file‑based workflows.
• Some commenters remain skeptical that local‑first can become mainstream beyond motivated, technical users, given usability expectations and current economic incentives.