Hoverwise — shared expenses PWA

The product

Hoverwise is a product designed, developed and operated by Paul Titov & Co. It is built for the moment a trip, shared apartment or group of friends stops being simple: several people pay, expenses use different currencies, someone settles only part of a balance, and nobody wants to reconstruct the maths from a group chat.

A group can invite people, add expenses and receipts, split costs equally or unevenly, and see the smallest practical set of transfers needed to settle. Hoverwise runs as an installable PWA in English, Ukrainian and Russian.

The studio designed the product end to end and continues to operate it: accounts with email, Google or Apple; groups with photos, dates and locations; expenses with multiple payers and receipt photos; balances; settlements; activity; and web push. There is no separate App Store or Google Play application. The PWA is the product.

Built around the ledger, not the interface

The interface offers four ways to split an expense — equally, by exact amounts, by percentage or by shares. Underneath them, the ledger keeps one canonical representation. Every split is normalised into owed amounts stored in integer minor units and accepted only when they reconcile exactly to the expense total.

That is a product decision as much as an accounting one. If rounding is allowed to invent money, the group will argue about the app rather than the dinner. A group can mix UAH, USD and EUR, with conversion based on rates from the National Bank of Ukraine.

Hoverwise is not a bank, payment processor or money-transfer service. It keeps the ledger and records settlements; the actual transfer of money happens between the people in the group.

What to pay next

Recording expenses is only half the job. The question people actually ask is who should send money to whom, and how much.

Hoverwise does not ask anyone to unwind a web of pairwise IOUs. It calculates each person’s net position, then uses a minimum-cash-flow calculation to turn those positions into a small, practical set of transfers.

Partial settlements are first-class. If someone pays part of what they owe while the trip is still running, that payment should keep its meaning rather than be rewritten into a different story.

A PWA by architecture, not by label

Hoverwise is meant to be opened from the home screen at a restaurant table, not rediscovered in browser history. The frontend is a static React, Vite and TypeScript build; the API runs on PHP and MySQL. Production does not require a persistent Node process.

This was a deliberate architectural choice. A consumer utility of this size does not need a second runtime to be a serious product. Ordinary virtual hosting is enough when the architecture is designed around that constraint.

Paul Titov & Co handles the product and software engineering behind Hoverwise, from the PWA experience to the ledger and settlement logic.

The shell may go stale. The money must not.

A service worker can cache the application shell so the installed app still opens without a network connection. It never caches /api or /uploads. Yesterday’s interface is recoverable. Yesterday’s balance presented as today’s is a different class of failure.

Installation is part of the product

A valid web manifest is not an install experience. On iPhone, Hoverwise treats Add to Home Screen as part of the product flow — explained in the interface rather than left as a footnote for people who already know Safari.

Engineering notes

The implementation of split normalisation, minor-unit accounting, minimum-cash-flow settlements, exchange rates, service-worker boundaries and iOS installation is covered in Hoverwise: PWA with a ledger that refuses to guess.