blindrange

Solo apps

Real software with no infrastructure behind it — no server, no account, no hosting bill, nothing to keep paying for. And still multi-user, because the shared part is the storage, not a backend.

A Solo app is one HTML file. It runs in your browser, derives its own keys from your passphrase, and reads and writes an encrypted database held by a public network of nodes that cannot read any of it. There is no API server in the middle. There is no company operating your account. Close the tab and nothing is running anywhere on your behalf.

The interesting part is what survives that deletion. Most "no backend" apps are single-player: your data lives in your browser, and sharing it means adding a server back. Solo apps keep the multi-user half — several people, several devices, one shared ledger — because membership is a key, not a login, and the database is a network rather than a machine.

Open one and use it

InvoiceFlow Solo icon

InvoiceFlow Solo

Invoicing for one person or a small company — customers, items, invoices, PDFs, dashboard, backup.

The third rebuild of the same product, with one variable moved each time: React + FastAPI + MongoDB, then the same app on blind storage, then this — no server at all. Invoice numbers are claimed on the network so two of your devices cannot mint the same one. "PDF" is a print stylesheet, because a page holding master keys runs nobody else's code.

Open InvoiceFlow Solo → source
backend: none pages, warmed: 2–9ms returning to a warm ledger: <1s first warmup: ~30s
Using it for real books? This runs on the public demo network — volunteer nodes, no uptime promise, and the honest place for a trial rather than your accounts. The same file points at your own nodes by changing one line. Everything the network can observe is written down on the leakage page; nothing there is a value, a name or a date, and none of it is a reason to skip reading it.

How a Solo app can have no server and still be shared

Your keys, in the pageA passphrase unlocks a master key that never leaves the browser. Records are sealed before they touch the wire, and every index key is a pseudorandom token derived from that master.
Membership is an invite, not a loginSharing a ledger means handing someone an invite string. There is no account to create, no password reset, and no administrator who could be compelled — because there is nobody in the middle at all.
The network is the databaseNodes store ciphertext under keys they cannot interpret. Range queries and prefix search still work, over an index built from the same blind tokens.
Local-first, so it feels like nothingThe app keeps an encrypted mirror in your browser. After the first warmup, pages answer in single-digit milliseconds and stay that way.

Multi-user is the part people expect to be missing, so it is worth being precise about what works and what it costs. Two people holding invites to the same ledger both read and write it. Writes carry the writer's identity, so concurrent edits merge by rule rather than by last-write-wins. Sequence numbers — invoice numbers, order numbers — are arbitrated by the network, so two devices offline at the same time still cannot collide. What you do not get is a server enforcing permissions: anyone with the invite has the ledger. Read-only sharing and per-field grants do not exist yet.

Where the application itself lives

A file served from a web host is a file that host can change. So the app is also stored in the database it runs on: a content-addressed copy sits on the network, and an ~80-line loader fetches it, verifies the hash in your browser, and only then runs it. The URL contains the hash, which makes the address the integrity check. Nobody can swap the app under its users — including us.

Being honest about the trade. Lose both your passphrase and your invite and the data is gone: the property that locks a storage provider out is the same property that locks you out. There is no reset link, because there is nobody to send it. Keep the recovery kit the app can export.

More Solo apps

Yours, possibly

The pattern generalises to anything a small team keeps in a spreadsheet and would rather not park on someone else's server.

Time tracking, client CRM, expenses, inventory, case notes, reading lists. If it is records with dates, amounts and names, and the sharing is "a handful of people I trust", it fits. Start from the browser guide — it is the same vendored client this page's app uses.

Build one →
Why this is not just "serverless". Serverless still means a provider running functions against a database they can read, bill and revoke. Here the storage cannot read the data, the app is not hosted anywhere in particular, and no account exists to be closed. The bill for keeping a Solo app alive, once it is written, is zero — that is the claim, and the apps page shows what it took to earn it.
blindrange.dev · built on blindrange · the browser guide · what leaks · demos · live network · source