Rolling Dices: from RPG companion to realtime virtual tabletop.

Tabletop RPG groups track character sheets, dice, rules, inventory, wounds, notes and position. Most virtual tabletops began with the map. We asked what software could manage without taking control from players or the game master.

We began with a phone companion for physical play, but the same session also had to work remotely. That set the product constraint: one responsive application, useful both beside the table and as the table.

The first release organised accounts, characters and invitations but barely touched play. Tests instead exposed the questions that mattered: what should each role see, who starts an action, and which parts of a session must persist?

The shared session replaced the account as the product centre. Its log joined conversation, rolls, story events and state changes; each shipped loop then exposed the next missing responsibility, from character context to resources and shared space.

One thing never moved: the fiction, and the game master’s authority to rule on it. Every rung was bookkeeping taken off the table — never a decision taken away from the people around it.

More rules removed more bookkeeping but made the product less generic. A configurable theme system was our answer — and the project’s most ambitious bet.

The called roll holds both the product idea and the architecture. A game master picked a player, attribute and difficulty; the engine derived the dice and persisted a pending action; the player rolled, and health, energy and equipment shaped a result that entered the shared log. Dice stayed the visible resolution, but the application understood enough context to evaluate the action and keep its consequences.

Mobile behaved like a tool belt: one focused context at a time, so the phone supported play at a physical table instead of competing with it. Our first assumption had been the opposite — the early product briefly blocked small screens. Phone use then became a core requirement, down to touch drag-and-drop on the combat board.

Desktop stopped behaving like a larger phone and became a workspace: party, Session Log, dice, Exploration and Board visible together, with infrequent operations opening as modal tasks. The domain model never changed; only the composition did.

Rolling Dices was a React and TypeScript single-page application backed directly by Supabase. Redux held identity and navigation, React Query held server projections, and high-frequency interaction — dice, dragging, selection — stayed local until it needed persisting. A separate engine layer calculated dice, derived statistics, XP, energy and initiative. Supabase replaced an application server, auth service and websocket layer at once: an unusually lean multiplayer architecture for three engineers, only one of them full-time.

The consistency pattern was event, invalidate, refetch. A browser wrote to Postgres, Supabase emitted a change, other clients invalidated the affected projection and refetched authoritative state. Realtime was not polish — it was the consistency model. Postgres also acted as a backend-for-frontend, with SQL functions composing UI-ready read models, while writes still hit several tables directly from the browser.

By early 2024 Rolling Dices held the complete outline of a browser VTT — characters, shared sessions, contextual dice, a persistent log, inventory, health, party resources, exploration, a combat board with initiative, terrain and vision. It could sit on phones around a physical table, or be the tabletop itself.

The breadth was real; the validation was not. We learned a great deal about how people play, but not enough of them were changing established behaviour in a way that justified continued investment. I closed the product in April 2024 rather than confuse technical momentum with market evidence. Founding a product means owning the stopping criteria as well as the vision.