About Bill-splitter

Why we built this

Anyone who has tried to split a restaurant bill with five friends knows the problem. One person had wine, two shared a starter, somebody left early. The existing options — even-split apps, expense trackers, group messages with screenshots — all need somebody to type every line into a spreadsheet first, and they all assume a level of trust and patience that disappears around dessert.

Bill-splitter started as a weekend tool to skip the typing. The OCR pipeline reads the receipt directly. The collaboration loop means everyone picks their own items in parallel rather than relaying through one person. And because every session lasts only thirty minutes, there's no account to create, no history to manage, and no reason to trust us with anything you wouldn't trust a paper napkin with.

The result is something small and specific — a single tool that does one thing properly — rather than the venture-funded super-app that tries to own every step of your social life. We think more of the web should look like this.

How it works under the hood

Three pieces, deliberately small:

• Browser OCR. When you drop a receipt photo, we run Tesseract.js, an open-source WebAssembly OCR engine, inside a Web Worker on your device. The image, the raw OCR text, your EXIF metadata — none of that ever leaves your phone. We use a forked-then-refined pipeline that handles JPG, PNG, HEIC, and PDF input across multiple languages.
• A tiny backend. Once the host taps Share with friends, we upload the structured Receipt object (items, quantities, prices, currency, vendor name, total) to a single small server. No database — sessions live as short-lived JSON files that delete themselves automatically. No long-lived process, no queue, no third-party state store.
• Live updates over plain HTTP. Each participant's browser opens a Server-Sent Events stream and receives updates as everyone claims items. No WebSocket, no app, no permissions to grant. We pick the architecture we can run on shared hosting because we'd rather keep the project cheap and honest than impressive on a slide.

The privacy stance

We made three commitments early and have stuck to them:

• The receipt photo never leaves your device. OCR runs in the browser. The original image is unreachable from our servers — not because we promise not to look, but because we never have a copy.
• The parsed receipt (items, prices, total, vendor) reaches our server only long enough for the group to finish picking. Sessions self-destruct 30 minutes after creation, or 5 minutes after everyone leaves. There is no archive, no backup, no log of past receipts.
• We never log receipt content. Server logs record only operational metadata — session ID, participant count, request timing — and a code-enforced scrubber prevents item names, prices, or vendor strings from reaching any log file even by accident.

The full breakdown lives on the privacy policy, which we try to keep readable rather than legalistic.

How we pay for it

Bill-splitter is free because the running costs are small — a single shared host, no database, sessions that delete themselves. We cover those costs with a single advertising slot on the landing page (no ads during the live splitting flow) and a one-time donation prompt the host sees after the bill settles. That's it. We don't have user accounts to monetize, we don't sell data, and we never will because the architecture doesn't let us.

If you'd like to support the project directly, the donation link at the bottom of the bill-splitting flow opens a Stripe Checkout page. Hosts receive payment directly; no Stripe code lands in our bundle.

Who runs it

Bill-splitter is built and maintained by a small independent team. There's no venture capital, no growth team, no roadmap chasing a Series A. If something breaks, the same person who wrote the broken code is the one who fixes it. Reach us at [email protected] for support, bug reports, takedowns, partnerships, or feedback of any kind.

Everything we ship is reviewed against our own use of the tool — we eat the same dogfood every time we go for dinner — and against a small set of real receipts that have historically broken parsers. If the OCR works reliably for those, it ships; if it doesn't, it doesn't.

What's next

We're focused on making the existing flow more reliable rather than expanding the feature set. Better OCR on glossy thermal receipts, smarter handling of shared appetisers, sharper support for international tax conventions — the small things that make the difference between "useful" and "actually delightful." If there's a particular receipt that broke or a scenario that feels clumsy, we'd love to hear about it.

Read the bill-splitting guide for the broader thinking behind the design, or skim the FAQ for the most common questions we get.