Splitwise already tracks debts. Splitkaro already reads SMS and itemizes food orders. GPay and PhonePe both have native split-expense features baked into apps that are already on everyone's phone.
What I wanted to build was one question, forced by three constraints set before writing a line of code: how do you design a payment-settling flow with zero accounts, zero backend complexity, and a payment rail you can't verify?
Not “how do you compete.” How do you make the one moment that matters — someone seeing what they owe and paying it — feel good, when you've deliberately taken away the infrastructure that usually makes an app feel trustworthy: a login, a server, a receipt that confirms the transfer went through?
The organizer fills in names and amounts, and gets back a link and a QR — no account created, nothing sent to a server. That same link is the share screen, the tracking page, and the record, all at once.
Nothing about this needed to be a receipt. A bill split is just numbers next to names — Splitwise does it as a list, GPay does it as a modal. A thermal receipt is one of the few pieces of paper everyone already has a physical relationship with: you've held one, folded one into a pocket, torn one off a machine at a counter. The moment a split shows up looking like something you'd get handed at a restaurant, it stops needing to explain itself.
A payment moment is usually cold — a form, a confirmation, a receipt you don't look at twice. The instinct here was the opposite: make the one second when money changes hands feel good, not just functional. Bold black outlines, hard offset shadows instead of soft blurred ones, a bit of spring and overshoot in the motion — paired with neo-brutalism's flat colors and hard edges, so it still reads as money, just money that doesn't take itself too seriously. Fintech-but-fun, not generic-fintech, not generic-toy.
But that playfulness had a hard boundary. A cartoon is a style that announces itself as fake — fun, but it breaks the one illusion the whole product depends on: that this receipt is real enough to tear. The little persona avatars can be playful. The print-out animation can be a bit theatrical. But the paper itself, the tear, the sound of the tear — those had to hold up to a stricter standard: does it look and sound like something with fibers in it, or like an app being clever?
So real physical rules got enforced everywhere it would've been easier not to. The edge attached to the slot stays straight, because that part of the paper hasn't been torn yet — only the leading edge gets serrated. The paper narrows into a rounded shoulder right where it meets the slot, because that's what a fold actually looks like, not a drawn crease line, which reads as decoration. Even the grain texture is there for the same reason: real thermal paper isn't perfectly flat or perfectly white, and a texture-less receipt quietly tells you it's not real, even if you can't say why.
The difference between an object that represents paper and one that behaves like it lives in details exactly this small.
The tear is the one moment a person actually feels something, and it had to carry real weight. Tapping your name and watching your stub physically rip away and fly off does something a “Pay Now” button never could: it makes an abstract transaction — money leaving your account — feel like a concrete, deliberate action you performed with your own hand.
Splitting a bill has always had an awkward middle step: someone reads out numbers, everyone nods, but the debt still just sits there as one shared, vague number — nobody's specifically on the hook until money actually moves. Tearing collapses that step into one physical gesture — you take your stub off the group receipt, and now it's specifically yours, not the group's. It's also the same motion that starts the payment. There's no second button after you've claimed your share, because in real life those two things are close enough to be one act.
That anticipation, and the wind-gush trailing behind it as it exits, exist for the same reason cartoon physics always has: to make an instant action readable, so it doesn't just happen, it's felt happening. The piece that flies isn't a rectangle with a tear-shaped picture on it — it's built from the same zigzag-edge generator as the print, so it genuinely looks ripped on both sides, not just cut loose from the bottom. The tear came first. The rest of the app exists to carry it.
You see paper rip, but the beat doesn't land in your body until you hear it. The first version of the tear sound broke this exactly: a filtered noise burst paired with a rising-then-falling sine sweep, and it sounded like a cartoon boing, not a rip. A pure tone is exactly the wrong texture for something that's supposed to be fibers snapping unevenly.
You can fake weight with a shadow. You can't fake the sound of paper with a clean, electronic tone.
It got rebuilt as a genuinely granular rip: roughly two dozen tiny noise bursts, twelve to thirty milliseconds each, randomized in pitch and timing, denser and louder where the tear starts and thinning out toward the end. No tone in it anywhere.
The tear sound is sharp and a little ragged on purpose, not clean — a clean tone would undercut the physical illusion the visuals just spent so much effort building. The whoosh that follows it is a separate, higher, faster sound layered right on the tear's tail, because a real tear-and-throw is two overlapping physical events, not one: the rip, then the object leaving. And the printer sound — the whir-and-ratchet as the bill “prints” out of the phone's slot on open — exists to make the very first thing a person experiences in the product feel mechanical and real before they've even touched anything.
Sound does the same job here as the paper grain and the fold shadow — a third channel convincing you this is a physical object, not a screen.
Groups, recurring splits, SMS or bank parsing, debt simplification across bills, any kind of login — all real temptations mid-build, all cut for the same reason: each belongs to a different, more ambitious product than the one this was trying to be. The closest thing to an account is a list of past links, saved to the browser and nowhere else. Payment verification is accepted as a permanent limitation of the rail, not a bug waiting on a fix.
It took until after deploy to ask the obvious question: does this need a license, a registration, anything filed with anyone? Neither NPCI's TPAP rules nor RBI's Payment Aggregator rules apply — this never signs a transaction or touches funds, it only hands off to an app that's already registered. India's DPDP Act applies in principle, but names, UPI IDs, and amounts live only in a URL fragment a browser never sends anywhere. What's real is a plainer risk with no regulation attached: the link itself, once shared, hands a UPI ID to whoever holds it. That's not a compliance problem, it's a design one.
Nothing here out-features Splitwise or Splitkaro, and it was never supposed to. What it argues is narrower: that a settle-up flow can carry real weight of craft — a physical tear, a receipt that never once claims to know if it got paid, a link that is the account — and still ship in a weekend, if the scope is held to exactly one interaction done honestly instead of ten done adequately.
Every decision above was made and corrected as a static concept — mockups, motion described in words, sound scoped but not built. That's the right way to settle a design direction, and the wrong way to finish one. The tear needed to actually respond to a touch, the print-out needed to actually play on load, the sound needed to actually sync to the motion frame by frame — none of that can be fully validated as a picture or a spec document.
The design rationale above got written into a spec first, and Claude Code built from it: the paper, the tear, the sound, laid out and built to that brief. What came after was a different kind of direction — reactions to something now actually on screen, not more spec. “The tear seems too cartoonish… currently it's like whoomp” isn't a request with an obvious next step — it's a feeling, aimed at code that already existed, asking for something closer to right. A single Pinterest link of paper coming out of a slot did more specifying than a paragraph could have. “It feels like a phone inside a phone” — said while looking at the receipt on an actual iOS Simulator, itself already a phone — cut an entire component in one sentence, because the problem was only visible once the thing existed to look at.
The code was rarely the bottleneck. The bottleneck, same as any design work, was noticing — and having a collaborator that could turn a reaction into a working revision fast enough to keep noticing.
Phaad — Hindi/Hinglish for “tear.” Set in Big Shoulders Display, Newsreader, and IBM Plex Mono — the last one is the same face the product itself is built in.
