Web Applications
A household ledger for two incomes and one joint account
Built by Rafael Bautista
A small budgeting app my partner and I actually use, mostly because it refuses to categorise anything automatically.
Builder email verified
Verification

- Type
- Personal
- Category
- Web Applications
- Published
- Jul 25, 2026
- Updated
- Jul 25, 2026
About this project
- What I built & why
My partner and I both earn, we split some things and not others, and every budgeting app we tried assumed one of those was not true. We spent about a year on a shared spreadsheet, which worked until it did not — the moment one of us edited it on a phone, something got broken. I built this over a few months of evenings, mostly as a way to stop having the same conversation about who paid for what. It is deliberately small and I have resisted every feature idea including my own.
- The problem
It solves the specific problem of two people with separate money and shared obligations. Every transaction gets marked as mine, theirs, or joint, and the monthly view shows what each of us owes the joint account rather than a single household total. That distinction is the entire product; a normal budget app collapses it and then the numbers mean nothing to either of us. It is for two people, and I have shown it to exactly one other couple.
- What I owned
Everything — schema, app, the import parser for our two banks' statement exports, and the deployment, which is a single container on a small machine I already pay for. The split logic is the part I have rewritten most: handling a joint expense that one person paid on a personal card, and reimbursements that arrive a month later, took three attempts before it stopped producing numbers we argued about.
- Technical & product decisions
The big decision was no automatic categorisation. Every import lands in an uncategorised pile and someone has to touch each row. Every app we had tried guessed, guessed wrong maybe fifteen percent of the time, and we stopped trusting the totals — a wrong number you believe is worse than a blank one. Doing it by hand takes about ten minutes a month and we both know what the numbers mean. I also kept it on SQLite with a nightly file copy rather than anything managed, because the data is small and I wanted the whole system to be something I could restore from a file.
- Hardest challenge
Reimbursements broke my model twice. If I pay for a joint dinner on my own card in March and the joint account settles in April, a naive ledger shows March as unbalanced and April as double-counted. I first tried to solve it by dating everything to the settlement, which made the monthly spending view useless. What works now is that a transaction has both an incurred date and a settled date, and the two views ask different questions of it. Obvious in hindsight; it took me a month of wrong totals to see.
- Result & impact
We have used it for two and a half years and the who-paid-for-what conversation genuinely stopped, which was the point. We also found roughly eleven hundred pesos a month of subscriptions neither of us had noticed, because forced manual categorisation makes you look at every line. The other couple I showed it to asked for automatic categorisation within a week, which I take as evidence the design is right for us and not for everyone.
- Who else worked on it
My partner, who is not a developer and is the reason the interface is as plain as it is. She vetoed three features and every one of those vetoes was correct.