I Built My Own Bill-Splitting App — Payments Is My Day Job, and I Wanted One Without Ads

I'm a Japanese software engineer in the Bay Area. I spent years doing payments at PayPal and now do payments at Atlas, a fintech startup. Ledgers, balances, reconciliation, rounding errors — moving money is literally my day job.

Was I desperate for a bill-splitting app? Honestly, no. My friends and I already used existing services like walica (a popular Japanese registration-free splitter) for some trips, and with another group we just passed around an Excel sheet. Both worked fine.

So why build one? The reasons are pretty simple:

• I didn't want ads. Something about an ad wedged into the middle of a money calculation has always rubbed me the wrong way.
• I don't know what happens to the data I type in. Who you were with, when, where, and how much you spent — split-the-bill data is a surprisingly intimate activity log once you think about it. What a free service does with it behind the scenes is invisible from the outside.
• I want the history in my own hands. Records of trips and dinners turn out to be a fun personal log to look back on. I don't want that living somewhere that disappears when a service shuts down.
• And frankly, as a payments engineer this is the dead center of my specialty. Settlement algorithms and remainder handling are problems I touch every working day. There was no good reason not to build my own tool.

One more design goal from the start: whatever I built had to be something I could hand to non-technical friends as-is — no app install, no account signup, just send one link and anyone can join. That requirement pays off later.

The result is Settli. This post covers the "why," a tour of what it actually does, and the most fun piece of engineering inside — the settlement algorithm that turns a messy pile of payments into a minimal "who pays whom how much" list.

About the contradiction: "I don't want to hand over my data" — says the guy storing his friends' data

Let me get an awkward tension out of the way first. I just said I dislike not knowing where my data goes — and yet Settli stores my friends' settlement data in my Firebase project. From their point of view, isn't my app just "somebody's random server" too?

After chewing on this, I think the difference isn't whether data is held, but the incentive structure around it. An ad-funded service has a structural economic motive to exploit data. A personal tool has none — there's no monetization, so the data has no use beyond rendering the settlement sheet. And the data itself is minimized by design: members are just typed-in names like "Yudai" and "Ken." No email addresses, no phone numbers, no accounts exist at all. The operator has a face (mine), can answer exactly what's stored if asked, and isn't storing much to begin with. As an explanation I can give my friends, I think that holds up.

What Settli actually is

Settli is a Next.js app with Firebase behind it. The design axis is the requirement from the top: nobody but the organizer ever needs to log in.

 Organizer                            Friends
 ─────────                            ───────
 Create group ─┐
 (name, currency,                     Receive link or QR
  member names,  │                        │
  optional 4-6   │                        ▼
  digit passcode)│             /tools/settli/join/A7K2M9PX
       │         │                        │
       ▼         │                        ▼
 Get share code ─┘────────▶   Group page opens.
 "A7K2M9PX"                   No signup. No install.
       │                      (passcode prompt only if set)
       ▼
 Log payments as they happen
       │
       ▼
 "Settle up" → minimal transfer list
 "Everyone sends one payment, done"

The main pieces — all of which exist in the code today:

• Account-free groups. The group's createdBy field is literally typed string | null. Anonymous creation isn't a degraded mode; it's a first-class path. Members are just names typed into a form ("Yudai," "Ken," "Aya"), not user accounts. Anonymous organizers get their recent groups remembered in localStorage; logged-in ones get a server-side history page.
• Share codes and QR. Every group gets an 8-character share code, generated from an alphabet that deliberately excludes 0/O and 1/I — because these codes get read aloud across izakaya tables. "Is that a zero or an O?" is a bug you fix in the alphabet, not in support. A QR endpoint exists for the same reason.
• Optional passcode. The share code is a capability — anyone holding it can view the group. Groups that want more can set a 4–6 digit passcode, and the server re-verifies it on every request instead of trusting a client-side "verified" boolean.
• Four split types. Equal (with per-member weights), percentage, fixed amounts, and shares. Each payment records who paid, who participated, a category, and a date.
• Multi-currency groups. Nine currencies supported. A trip that mixes yen payments and dollar payments becomes two independent settlement sheets. The tool doesn't pretend to know an exchange rate you'd both agree on.

The weights feature deserves a sentence, because it's exactly the kind of thing you can't get from an off-the-shelf app: <!-- TODO(Yudai): replace with the real group rule — lighter share for non-drinkers, kids count as 0.5, etc. --> it encodes my group's unwritten rule that certain people count as less than one full share for certain expenses. A group-chat argument became a product feature. That's the dividend of building your own.

The fun part: the settlement algorithm

Here's the engineering core. A trip ends and you're left with a pile of payments. Done naively, settlement is per-payment: 23 payments × 5 people means up to 23×5 transfers. Nobody does that, obviously — so what's the minimum?

Settli does it in two stages.

Stage 1: collapse everything into one balance per person. For each payment, compute each participant's share according to the split type, then per person: balance = total paid − total owed. Positive means the group owes you; negative means you owe the group. By construction the balances sum to zero.

Stage 2: greedy matching. Sort creditors and debtors descending, then repeatedly have the largest debtor pay the largest creditor as much as possible.

interface Balance {
  memberId: string;
  amount: number; // positive = creditor, negative = debtor
}

function settle(balances: Balance[]): Transfer[] {
  const transfers: Transfer[] = [];
  // Below this we don't care: ¥0.5 for yen, $0.005 for decimal currencies.
  const threshold = 0.5;

  const creditors = balances
    .filter((b) => b.amount > threshold)
    .sort((a, b) => b.amount - a.amount);
  const debtors = balances
    .filter((b) => b.amount < -threshold)
    .map((b) => ({ ...b, amount: -b.amount }))
    .sort((a, b) => b.amount - a.amount);

  let i = 0, j = 0;
  while (i < creditors.length && j < debtors.length) {
    const pay = Math.min(creditors[i].amount, debtors[j].amount);
    transfers.push({ from: debtors[j].memberId, to: creditors[i].memberId, amount: pay });
    creditors[i].amount -= pay;
    debtors[j].amount -= pay;
    if (creditors[i].amount <= threshold) i++;
    if (debtors[j].amount <= threshold) j++;
  }
  return transfers;
}

(This is a simplified version of the real code — production carries member names, per-currency rounding, and multi-currency grouping — but the algorithm is exactly this.)

A concrete four-person trip:

 Balances after stage 1:
   Aya   +9,000   (paid the Airbnb)
   Yudai +1,000
   Ken   -4,000
   Mei   -6,000

 Greedy matching (largest vs largest):
   Mei  ──6,000──▶ Aya      (Aya's remainder: +3,000)
   Ken  ──3,000──▶ Aya      (Aya settled. Ken's remainder: -1,000)
   Ken  ──1,000──▶ Yudai

 23 payments → 3 transfers.

Two things worth stating honestly — the parts blog posts usually oversell:

1. Each loop iteration fully settles at least one person (whichever side of the pair had the smaller balance), so for n people you get at most n − 1 transfers. That's the greedy guarantee.
2. Greedy isn't always the theoretical minimum. When some subset of balances happens to cancel exactly, a perfect matcher could shave off one more transfer. But finding the true minimum means hunting zero-sum subsets, which explodes combinatorially — and for five friends the difference is at most one extra tap in a payment app. Knowing exactly where your algorithm is suboptimal, and deciding not to care with reasons — most of engineering is this.

A payments engineer's aside: who eats the remainder?

Split ¥10,000 three ways and you get ¥3,333.33… — someone eats the extra yen. At work, this class of problem — allocation rounding — is the main ingredient of reconciliation reports and tense accounting Slack channels. A bill-splitting app still has to pick a policy; it just gets to pick a friendlier one.

Settli's policy has three layers:

• Round per currency, not per habit. Yen and won have no practical sub-unit, so balances round to whole units; the dollar family rounds to cents. A splitting app that shows a Japanese user "¥3,333.33" has already lost their trust.
• Round at the balance level, not per payment. Shares stay floating-point, get summed into each person's balance, and are rounded exactly once — so rounding error can't accumulate across 23 payments.
• Let the threshold eat the dust. The settlement loop ignores residuals under ¥0.5 (or half a cent). Effectively, the creditor of the rounding dust silently forgives it. Among friends that's the right policy — nobody wants to receive a ¥1 bank transfer. Do this in a production ledger at work and it's an audit finding (you track remainders in a rounding account and allocate them deterministically). Same math, different social contract. On weekdays I guarantee not a cent goes missing; on weekends I write code that deliberately shrugs at half a yen. I find this genuinely delightful.

There's also a display-level rule: suggested transfers in yen round to ¥10 units, because "send ¥4,237" is technically correct and socially insane.

The honest trade-off ledger

Building your own doesn't mean "better." It means a different cost structure. What I gave up:

• No mobile app, no push notifications. Settli can't nudge Ken that he still owes ¥4,000. That's the group chat's job. Clear win for commercial apps.
• No receipt scanning, no bank sync. Amounts are typed by hand. Fine for a weekend trip; you'd hate it as a daily household budget tool.
• Settlement stops at a suggestion. Settli tells you who pays whom; the actual money moves over Venmo, PayPay, or cash. Yes, I see the irony of a payments engineer's splitting app that doesn't move payments — but embedding real transfers means KYC, compliance, and liability, and everything pleasant about this tool comes from carrying none of that.
• Maintenance is mine forever. When a dependency gets a CVE or Firebase raises prices, there's no vendor. The flip side of "nobody can enshittify this under me" is "every problem this tool ever has is my problem."
• Trust-based access. Share code + optional passcode is capability security, not identity security. Correctly calibrated for splitting dinner; I would not run a company on it.

What I got: a tool whose entire onboarding for friends is "tap this link." A tool whose split rules match my actual group's actual norms. A tool where I can explain exactly where the data lives and what it's used for. Zero ads. And a tool where every annoyance gets fixed the same week I hit it — because the feedback form and the maintainer are the same person.

What I want to build next

• Per-transfer settlement tracking — mark individual suggested transfers as "paid," not just the whole group as settled.
• Single-currency view (opt-in) — a "convert everything to yen at an agreed rate" mode that collapses a multi-currency trip into one settlement sheet.
• Recurring groups — a standing "monthly izakaya" group that auto-archives each month's sheet.

Try it here: meetyudai.com/tools/settli — no signup. That was the whole starting point.

Takeaways

• The motive wasn't "this is broken" — it was "this feels wrong." Existing services and Excel settled the bills fine. But the ads, the invisible data trail, and the history living only on someone else's server felt wrong. A personal tool makes that feeling go away.
• Answer the "but you store your friends' data too" contradiction with volume and incentives. Store only names, monetize nothing, be an operator with a face. Have an explanation you could give your friends out loud.
• Greedy min-cash-flow is 30 lines and guarantees ≤ n−1 transfers. Know the cases where it's not optimal, and decide not to care — with reasons.
• Rounding is policy, not arithmetic. Round per currency, round at the balance level, and decide explicitly who eats the remainder. Among friends, "nobody eats anything under half a yen" is fine. In a real ledger it isn't.
• The dividend of building your own isn't features — it's the feedback loop. Commercial apps win on features. Mine wins because my group's rules are the spec, and every annoyance is one PR away from fixed.