Why Rooms exists

Shared money problems are rarely arithmetic problems. They are problems of commitment, timing, social pressure, changing plans, missing proof, and memory — and they begin long before anyone pays. Existing tools enter after the money has moved; by then, one person has already fronted the villa and become the group’s bank. Rooms begins earlier: purpose, people, rules, and deadline are agreed first, and money is one coordinated object inside that agreement, never the whole product.

So the core object here isn’t an account or a transfer — it’s the room: a living, auditable container for one commitment, with a beginning, members, rules, money states that never blur, a complete record, and a clear close. When the last promise lands, the loop closes, and the history stays readable for everyone who lived it.

We are not building a bank, a wallet, or a bill-splitter, and we don’t use their language. The competition is the group chat plus a spreadsheet plus somebody’s patience — and the measure of success is that people finish a session feeling relieved, not exhausted.

Rooms is being built in a deliberate sequence of seven sprints — domain model and design language first, then accounts and rooms, then real payment partners, then depth. What you’re looking at now is the middle of that sequence: a working product in a sandbox reference stage. Accounts, rooms, commitments, and the record are real; the money and the email are simulated, and every surface that touches them says so.

Building in the open cuts both ways, so here is the other half: there is no invented team page here, no investor logos, no press quotes, no user counts. Not because those things don’t matter — because we won’t fabricate them, and right now there is nothing real to list. When there is, it will appear here, and it will be checkable, like everything else in the product.