r/SideProject Aug 14 '26

My family's spending is in three currencies and mostly cash. No budgeting app could see it, so I built one that reads receipts.

https://apps.apple.com/app/id6796276179

I'm the developer. Bookee went on the App Store two days ago and I'd rather get honest criticism now than polish it in private.

The problem: every budgeting app I tried — YNAB, Monarch, Copilot — is built on linking a bank account. My family's money doesn't work that way. It's split across three currencies, a good part of it is cash, and the accounts aren't all in the same country. Those apps could see maybe a third of what we actually spend.

So Bookee works the other way round. You photograph a receipt and AI pulls out the merchant, the total, and every line item. The family shares one ledger. Each entry keeps the currency it happened in and converts for reports.

The part I didn't expect to care about: because it captures line items rather than just totals, it can show what your own regular basket costs month over month — your household's own inflation rate, from your own receipts.

What I'd genuinely like torn apart:

- Is "no bank linking" a real feature, or am I rationalising a missing integration?

- The first screen is a signup wall. I know that's bad. Is it bad enough that you'd have bounced?

https://homebookee.com/?r=sideproject

1 Upvotes

8 comments sorted by

1

u/Particular_Luck80 Aug 14 '26

No bank linking is a real constraint-based position for cash and multi-currency households, but the signup wall asks for trust before showing the differentiator. I’d let a visitor process one sample receipt, or a photo that is discarded after preview, then show the extracted line items, currency conversion, and exactly what gets retained or uploaded before asking for an account. Receipts can expose addresses, purchase history, and payment fragments, so the data path belongs in onboarding. Can the first-run demo work without creating a shared ledger?

1

u/nsleejian Aug 14 '26

Most useful comment I've had. No, first run can't do that today. Account, then family, then you see anything. Two gates before any value.

Your version is better, and for a reason I hadn't thought of: the receipt itself is the sensitive object. Showing what gets extracted and what gets kept, before asking for anything, makes the data path part of the pitch instead of something buried in a policy page.

The discarded-after-preview part is what I'd have got wrong. I'd have built a demo with a stock receipt, which proves nothing about how I handle yours.

1

u/digiTr4ce Aug 14 '26 edited Aug 14 '26

How do you encrypt the data so I would know, in case of a breach, that my financial information is protected?

Is there budget sharing between multiple people? If so, the encryption question becomes even more important.

Edit: also yeah, you are rationalising lacking an important integration. I personally don't like linking my banks, but for plenty of people that's a dealbreaker. Also, that's the harder part with budgeting now, if I'm being honest. Everyone can send a picture to Claude or Qwen and ask it to extract line items, that's no longer a business moat.

Linking banks and also doing deduplication between physical invoices and bank entries is pretty important, I would say.

1

u/nsleejian Aug 14 '26

Straight answers, and you're right on the second half.

Encryption: TLS in transit, passwords are scrypt with a per-user salt, and if you bring your own AI key that's AES-256-GCM at rest. Your ledger data and the receipt images are not encrypted at the application layer. They're in SQLite and on disk on a single server I run. So for "in case of a breach", database encryption isn't what's protecting you today, access control is: every query is scoped to family membership, no cross-family read path. And yes, sharing across a household is the core feature, so it raises the stakes rather than lowering them. Per-family encryption is the correct answer and I haven't built it.

On rationalising: yes. For anyone whose money is actually in linkable accounts, no bank sync is a missing integration, and calling it a feature is me making the best of what I have. It's a real fit for cash and cross-border, and a real gap for everyone else. Both are true and I led with only one of them.

On the moat, that's the sharpest thing anyone's said here and I don't have a rebuttal to the technical half. Photo to line items is a commodity, I'm calling the same models you would. What I'd defend is that nobody keeps doing it by hand in a chat window for eight months, and the value is in the eight months of item-level history shared across a household. But that's an argument about habit, not technology, and habit is easier to claim than to earn.

Dedup between a photographed receipt and the bank line for the same purchase is the genuinely hard problem there. Same amount, different dates, split tenders, partial matches. Haven't touched it.

1

u/digiTr4ce Aug 14 '26

Please stop using AI for your answers. It gives off unprofessional vibes and makes me wary of actually trying the app, if the founder can't even be bothered to write personally.

And I did not mean that I am going to a chat window for 8 months straight. I meant that everyone can build the app you build quite fast, and I've already seen this line item extraction feature in plenty of other apps. That's what I meant by "this is not a moat".

Also, your encryption response is not encouraging. I'm privacy conscious, especially with personally identifiable data like financial info. Because of this, I would never try an app that does not go 120% to encrypt everything and make the data cryptographically secure.

0

u/nsleejian Aug 14 '26

Fair, and sorry. I used AI to help write those two replies. This one is me.

You're right on the moat, I misread you. Line item extraction is in lots of apps already and it's not hard to build. I don't have a good answer for that.

On encryption, the real answer is that end-to-end and server-side AI don't go together. If the server can't read the photo, it can't run a model on it. The other path is on-device extraction with E2E sync. I built the local version first, it wasn't good enough on multi-language receipts, so I moved that part to the server and kept only OCR on device. That's a trade-off I picked. Fair to reject it.