Forget installation wizards, cloud accounts, and versioned file formats. Bento ships an entire presentation suite — editor, viewer, embedded data, and real-time collaboration — inside a single .html file you can open in any browser. That is not a demo trick. It is a deliberate architectural statement, and it deserves a serious look from anyone building software today.

The Single-File Architecture, Explained

Most productivity tools are icebergs. The interface you see floats on top of servers, databases, authentication layers, CDN assets, and API gateways. Bento flips that model. Everything the application needs — logic, styles, content, and state — lives in one self-contained document.

This is possible because modern browsers are, functionally, operating systems. The Web Platform now provides:

  • Local storage and IndexedDB for persistent state without a backend
  • Web Crypto API for client-side encryption and identity
  • WebRTC and BroadcastChannel for peer-to-peer or tab-to-tab communication
  • ES Modules and dynamic imports for structured JavaScript without a build step
  • Blob URLs and the File System Access API for reading and writing files locally

Combine these and you can build software that genuinely runs offline, shares easily (email, USB drive, a static host), and leaves no data footprint on a third-party server.

Why Collaboration in a Single File Is Hard — and Interesting

Collaboration is the feature most likely to break the single-file promise. Conventional wisdom says you need a central server to broadcast changes between users. Tools like Figma and Notion rely on operational transformation or CRDT algorithms running server-side.

Bento sidesteps the server requirement by leaning on CRDTs (Conflict-free Replicated Data Types) coordinated through WebRTC signalling or a lightweight relay. The file itself becomes the source of truth that any peer can hold. This is the same intellectual lineage as Git — a distributed, merge-friendly data model — applied to a presentation document.

For software teams, this surfaces a genuinely useful design pattern:

User A (local file) ──WebRTC──► User B (local file)
        │                               │
        └──── CRDT merge ───────────────┘
                   │
            No central DB needed

When both peers reconnect after going offline, their local states merge deterministically. No conflict dialogs, no lost edits.

What This Means for SaaS Founders and Product Teams

1. "No Backend" Is a Legitimate Product Strategy

Not every SaaS needs a server. If your core value proposition is around documents, reports, dashboards, or presentations, a local-first approach can dramatically lower your infrastructure costs while improving user trust — especially in markets where data sovereignty concerns are high.

In Ghana and across West Africa, many enterprise clients are cautious about where their data lives. A tool that keeps sensitive information on the client's own machine, with optional sync, is a competitive differentiator, not a limitation.

2. Distribution Becomes Trivially Simple

A single HTML file can be attached to an email, hosted on GitHub Pages, dropped into a WhatsApp group, or served from a basic Nginx instance. There is no Docker container to configure, no database migration to run, no environment variables to set. For internal tools, prototypes, and client deliverables, this simplicity has real commercial value.

3. The Offline-First Mindset Improves All Software

Even if you are building a conventional SaaS with a backend, the discipline of thinking about local-first state management produces better architecture. Applications that treat the server as a sync target rather than a single point of truth are more resilient, faster, and easier to test.

Libraries like Yjs, Automerge, and ElectricSQL bring these patterns to mainstream web development. Bento is a high-visibility proof of concept that the approach works in production.

The Trade-offs Are Real

Intellectual honesty requires acknowledging what the single-file model gives up:

  • Access control is hard. Sharing a file means sharing everything in it. Granular permissions require either encryption complexity or a server.
  • Large media assets (video, high-resolution images) bloat the file to impractical sizes.
  • Discoverability and search across many files requires external tooling.
  • Audit trails and compliance logging almost always need a backend.

These trade-offs do not invalidate the approach. They define its appropriate use cases: documents, lightweight presentations, internal dashboards, data reports, and collaborative whiteboards where the team controls distribution.

The Broader Trend: Tools That Respect User Ownership

Bento sits inside a wider movement — local-first software — championed by researchers at Ink & Switch and implemented in tools like Obsidian, Logseq, and now Bento itself. The common thread is that users own their data as files, not as rows in someone else's database.

For developers, this is both a technical opportunity and a business model question. Subscription fatigue is real. Users increasingly value tools they can run without a live internet connection and without worrying that a price change or shutdown will lock them out of their own work.

Building around open file formats and client-side compute is not just idealism — it is a durable competitive position.

Why This Matters for Your Project

If you are scoping a new internal tool, a client-facing report builder, or a lightweight collaboration feature, the single-file pattern is worth prototyping before you stand up a full backend. The Web Platform is powerful enough to surprise you, infrastructure costs are real, and user trust around data ownership is a growing purchase criterion — particularly in enterprise and public-sector deals. Start local-first, add a sync layer when you actually need one, and you may find you ship faster and retain users longer.

Source: Bento — https://bento.page/slides/ via Hacker News