Built on blindrange
InvoiceFlow
The first production application to run on this network with no other database behind it. The cutover was earned, not announced: dual mode first, every record written to MongoDB and blindrange side by side with count verification at each step, then a final drill that killed the network for 40 seconds in production — reads kept answering from the local mirror, and the one write caught in the outage landed when the network returned. Then Mongo was retired. The app keeps its keys; invoices cross the wire sealed; the nodes store records they cannot read.
It also shaped the engine. The local-first mirror,
KEY columns, network-atomic sequences, one-barrier
batching and the refusing-absence-from-silence rule each exist
because this migration hit the wall they remove.
InvoiceFlow Solo
Every rebuild moved exactly one variable: MongoDB SaaS, then blind-storage SaaS, now no server at all. Keys are derived in the page, invoices sealed in the page; auth is an invite, numbering is network-arbitrated, and "PDF" is a print stylesheet because a page that holds master keys runs nobody else's code.
And the part that answers "where is it hosted": the application is stored in the database it runs on. A content-addressed copy lives on the network itself; an ~80-line loader fetches it from blind storage, verifies the hash in your browser, and only then runs it — nobody can swap the app under its users, which is the defense web3 dapp frontends never had.
It is also multi-user, which is the half people assume a no-backend app has to give up: an invite shares the ledger, writes carry their writer's identity and merge by rule, and invoice numbers are arbitrated by the network so two of your devices cannot mint the same one. What it does not have is a server enforcing permissions — anyone holding the invite holds the ledger.