What Spendthrift is.

A personal finance app that budgets and splits shared bills in one place.

Spendthrift is a personal finance application for Android and iPhone. It combines two things this market has always kept apart: planning where a household's income goes, and settling shared expenses between friends, flatmates and family. Because both live in one app on one device, it can do what neither kind of product can do alone: when a shared bill is paid, the payer's own share flows into their budget as spending, and the remainder is recorded as money owed back to them.

The design rests on a single engineering decision: your financial records stay on your own phone. The arithmetic runs there, and so do the features that read receipts and bank statements, on the phone's own processor rather than a paid service. Where information does travel between the members of a group, it is scrambled before it leaves the device, and our server passes it along without being able to read it. The app is fully usable with no account and no internet connection.

That decision also settles how the business earns. With almost nothing to run per customer, the app can be sold once, buying this version and every update to it, permanently: no advertising, no feature held back for a higher tier, and no need to mine or sell what you record. A next major version, years away on an eight year cycle, is its own purchase, and nobody is ever pushed onto it. Splitting a bill is free for everyone, permanently, including people who never install the app; the budgeting is what is paid for, once. We never hold, move or have sight of your money: settling up opens your own payment app with the details already filled in, and the app records the outcome.

The result is a product whose commercial interest and its users' interests point in the same direction, which is unusual in this category, and is the reason the promise can be kept.

The story.

We did not set out to build a finance app. We were introduced to budgeting through envelope budgeting, became users first, and builders some time later, once the irritation had had a while to work on us.

The irritation was not that the software was bad. It was that it was cut in half. One app knew what we owed people. Another knew what we could afford. Neither understood the whole event, and both charged rent for their half of the view. Split a dinner four ways and your budgeting app records that you spent the entire bill. It is wrong, you know it is wrong, and there is nothing you can do about it except keep a second app open and do arithmetic that a computer should be doing.

So the plan was the obvious one, and it was the plan everyone in the category uses: import the bank statements, classify them afterwards, show people where their money went.

An accountant we brought the plan to took it apart.

Her first objection was that it produces accurate history and changes nobody's behaviour, because by the time you see the transaction the money is long gone. Her second was harder. It frequently cannot be done at all. Pay a shopkeeper by UPI and the statement shows that shopkeeper's personal name. Tap a card and it shows a payment processor nobody recognises. Thirty days later you have no idea what either was, and no amount of artificial intelligence recovers information the statement never contained.

Then she made the point that changed the shape of the product. A monthly review produces "I'll do better next month", which is a resolution, and resolutions fail. A weekly one produces "I'm spending a lot on food this week", an observation you can still act on, because the week is not over.

The plan was rebuilt around her objection. Capture close to the moment came first. Statements were demoted to catching what was missed. The rhythm became weekly rather than monthly. And two further ideas arrived that turned the remaining weaknesses into the product itself: that when the app cannot tell what a payment was for it should ask rather than guess, because being asked is how a person actually learns where their money goes, and that a group expense should flow into the payer's own budget automatically, which the budgeting method and the group-splitting method had never done together, because they had always come from separate companies with separate databases.

That last idea is the whole reason this exists. Split a dinner and only your share lands in your food budget. The part you fronted for everyone else sits in its own line, owed to you, where it belongs, because it was never your spending.

The rest follows from two convictions that predate the product. The first is that software should earn the right to know something about you, which is why nothing readable leaves the phone, and why that is an architectural property rather than a policy. Policies change with ownership, properties do not. The second is that software which helps you control your money should not extract rent from you for doing it, which is why this version is bought once, with every update to it included, and only a next major version, years away on an eight year cycle, is ever its own purchase.

Asked what would happen if a buyer offered a great deal on condition that the privacy architecture changed, we wrote the answer down before anyone had asked: no, and the price does not matter, because otherwise privacy was not a principle, it was only positioning.

And asked what we want said about it one day, by someone with no reason to be kind: that whoever built this clearly cared about doing it properly, and did what they said they would do.