We built an IOU tracker that logs favors and chores, not just money — with React Native and (yes) PHP

Sean — Mon, 03 Aug 2026 14:15:12 +0000

Every expense splitter my friend and I tried answered exactly one question: who owes how much money. But the things we actually forget aren't only money — the drill someone borrowed, the "I'll get you next time" favor, whose turn it is to do the dishes. None of the money apps could hold any of that.

So we built IOweU: an IOU tracker for money, borrowed items, favors, and tasks/chores in one place. This post is less a pitch and more a "here's what we built and the two choices people keep asking about" — and a genuine question at the end I can't answer from the inside.

What's actually different

Either side can create the IOU. You don't wait for the other person to log it — you can record what you owe, too.
It's not just money — borrowed items, favors, and tasks/chores are first-class.
The other person can accept, reject, or propose a change instead of you editing it on them.
An IOU can be reassigned to a third person instead of deleted and recreated.
For families, parents assign chores with an optional reward, and a completed chore turns that reward into a normal IOU.

The interesting engineering bit: an IOU is a shared state machine

The part that turned out to be more work than expected: an IOU isn't a record one person owns — it's a shared object two people mutate, and every transition has to be legal from both sides. Ours moves through states like proposed → accepted / rejected / withdrawn → (changes proposed) → settled / waived / reassigned, with notifications firing on each transition so both sides stay in sync.

That's a small distributed-consensus problem hiding inside a consumer app. "Who is allowed to do what, in which state" is the real domain model — not the money field everyone assumes is the hard part.

Why React Native

Two people, two platforms, one shared domain model that has to behave identically on both. RN let us keep that logic in one place instead of maintaining two native implementations of the same state machine. For a team this size it wasn't really a debate.

Why a PHP backend (the one people raise an eyebrow at)

We already knew PHP well, and boring, well-understood tech let us ship instead of learning a new stack. The backend is mostly state transitions, auth, notifications, and persistence — nothing that needed anything trendier. "Use the thing you can move fastest in" beat "use the thing that looks good in a post." Cheap to host, easy to reason about, and it hasn't been the bottleneck.

The question I actually can't answer

Here's what I genuinely can't judge from inside the project: is "track more than money" a real need, or are we bolting features onto something that should just stay a spreadsheet? Every user who tells us they love the item/favor tracking is offset by a worry that people only ever actually log money.

If your money-only app already does everything you need, I'd honestly like to hear that — that's the most useful feedback we can get right now.

It's free (no in-app purchases), on iOS and Android: https://iou.2genio.us