Let me be honest about the tradeoff. Sending receipts to a server would have been easier for me to build, cheaper to run, and simpler to make "smart" over time. Most scanning apps do exactly that. I decided not to.

The reason is simple: a receipt is a record of where you were, what you bought, and when. That's your life, not mine to hold. Once a photo leaves your phone, you're trusting a company's servers, its staff, its breach history, and its future owners. I didn't want to ask you for that trust — so I built it so I never have to.

What "on your phone" actually means

Capture, text recognition, AI extraction and the spending chat all run locally. Your receipts and amounts live in a database on the device. There's no account and no sync, and the core flow works with the network switched off entirely.

The app touches the internet for only two things: checking whether an update exists, and processing a purchase through the App Store or Google Play. Neither one carries your financial data.

What it costs

On-device means I can't peek at aggregate data to find bugs, I can't fix a bad extraction on a server overnight, and the AI has to be small and efficient enough to run on a phone you already own. Those are real constraints. I think they're worth it, and the roadmap is how we improve within them — together.

When you photograph a receipt, three things happen in sequence, all on the phone. First, the image is cleaned up and the text is read. Second, an AI model I fine-tuned decides which text is the merchant, which number is the total, which is the date, and which lines are items. Third, the result is written to your local database as a structured expense you can edit.

Why Thai receipts were the hard part

Generic scanners are trained mostly on tidy English receipts. Real life in Thailand is messier: mixed Thai and English, faded thermal paper, unusual layouts, Buddhist-era dates. I trained and evaluated against thousands of these real receipts specifically so the app holds up where others quietly fail.

Why I won't name the models

People ask which model or runtime is under the hood. I keep that private on purpose — not to be cagey, but because it changes. As better on-device options ship, I swap them in. If I put a brand name on the box, I'd be tying a promise to a component I intend to replace.

The promise that doesn't change is the one worth printing: it runs on your device, and your receipts never leave it. That's the part I'll defend regardless of what's inside.

The three most-requested features right now are recurring-expense detection, budget goals with gentle alerts, and encrypted local backup so you can move to a new phone without ever using a cloud. All three fit the rules: they run on-device and keep your data yours.

I build the top-voted items first. That's not a slogan — the order on the roadmap literally reorders my week. If something you need is low on the list, the fastest way to move it up is to add it and rally a few votes.

What I'm deliberately saying no to

Anything that requires uploading your data. A social feed. Ads. "Insights" that are really just a reason to phone home. If a popular request breaks the privacy promise, I'll explain why it can't happen rather than quietly shipping it.

I want to set expectations I can actually keep. I have a full-time job and a family I spend time with, and SnapSpend is built in the hours around them. I would rather promise less and deliver it than promise the world and ghost you.

So here's the honest version: as SnapSpend grows, updates come faster. Early on, that means steady maintenance and bug fixes. As it earns enough to justify more of my time, it moves to regular monthly updates, and then to twice a month. The support page lays out the exact cadence per stage.

One thing never scales down, though: I read every message, and I'll never leave you on read — even if you turn out to be the last person using this app. That part isn't tied to revenue. It's just the deal.